Adding comments to groups of changes?

[Peter Arrenbrecht]

On Tue, Jul 1, 2008 at 10:19 PM, Sean Russell <hg at ser1.net> wrote:
> 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.

It might be helpful to have switches that turn grouping on and off for
`hg log`. Default should be off (for the sake of compatibility). Then
one can use the [defaults] section in .hgrc to turn grouping on by
default for oneself, and again override this ad-hoc on the command
line.
-parren