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