Adding comments to groups of changes?
Sean Russell
hg at ser1.net
Tue Jul 1 15:19:09 CDT 2008
On Monday 30 June 2008 03:40:56 am Arne Babenhauserheide wrote:
> The groups already get merged, pulled, pushed, etc. since they are simply
> implemented as commits of the .hggroups file and are read out using hg
> annotate, so everything which pulls changes to files and the history will
> also pull groups.
I was thinking more about the ability to bundle meta-patches by a given group
name. For example:
hg group 78 80 85 # Creates, say, 86
hg bundle -r 86 bundle
hg export -o patch 86
# or
hg email -r 86
It would be handy if 86 was a meta-bundle. But the more that I think about
this, the more ambiguous/difficult to implement it would be. For one thing,
you wouldn't be able to apply just 86, because of missing parents,
so 'bundle' is probably not a likely candidate. However, email/export would
be useful. groups would have to recognize when what's being generate is a
group revision and pull in the patches for the revisions it depends on.
Oh, and if you're keeping track of a wish list, an -m option (a-la commit) for
group would be nice: hg group -m "My group" 2 4 7
Also, does anybody have any idea how to get rid of the overrides warnings that
HG generates ("extension 'group' overrides commands: ^log|history")?
> For update it would be nice to have Mercurial update to the most recent
> revision inside the group instead of to teh groups revision, though, since
> the group might be added later, and so updating to it might not always give
> the real work doen for it.
I don't mind the way it works now... it seems to make the most sense the way
it is.
> But please mind the status of the code: I did this as a proof of concept.
> While I hope that the concept is good enough that I won't have to change it
Hah! You've let the cats out of the bag now. Good luck avoiding feature
creep :-)
> (and using it will, at the very worst, put very small changesets into your
> history which might become useless, if the concept proves flawed), there's
> always the chance that I overlooked some glaring error.
Nobody has voiced any, so far, and I *really* like the concept. It provides a
less-often-used, but sometimes, needed feature: the ability to associate work
together. This is very useful for large repositories with many developers,
and provides a nice tool for code and history analysis.
> And the log command which overwrites the default log only offers basic
> usage at the moment.
Hm. I'd like to have the ability to expand the log, if for no other reason
than to see the commit messages. In fact, I'd rather have it be expanded by
default, and collapsed optionally.
Thanks Arne,
--- SER
More information about the Mercurial
mailing list