Concatenating changesets

Russ Brown pickscrape at gmail.com
Sat Dec 15 13:43:45 CST 2007


Matt Mackall wrote:
> On Fri, Dec 14, 2007 at 12:36:49PM -0800, John D. Mitchell wrote:
>> On Dec 14, 2007 11:00 AM, Matt Mackall <mpm at selenic.com> wrote:
>> [...]
>>>> Is combining changesets a bad idea (amd I still thinking in CVS),
>>>> or are there other, faster ways to do this with hg?
>>> I think yes, it's a bad idea. But various people are fond of it. And
>>> there are various faster ways to do it. Mq is probably the preferred method.
>> Why do you think it's a bad idea?  Especially if you like the use of
>> mq (in general, if not for this specific use case)?
> 
> A changeset should be a single well-defined change. Which means it
> generally should be small. Combining changesets is generally (but not
> always) a step in the wrong direction.
> 

I agree with this completely. However, I often find that a given range 
of changesets need to be considered as a set or they make little sense 
on their own (i.e the logical steps to developing a larger change). This 
brings me to a feature that I think would be really useful: some concept 
changeset 'grouping'.

I haven't thought at all through the details of how it could work, but 
something that would allow changesets to be identified as a set, with 
perhaps some common comment for the grouping would be very useful indeed 
for adding context and improving the commentary of history.

That would give you the advantages to small incremental changesets 
(since the underlying operation would not change) but also give the 
benefits of larger changesets since I'd anticipate that the tools would 
allow you to do things like view the combined diff of the entire 
changeset group. One way would be to give the set a changeset name, so 
the set's name can be used anywhere that a changeset name can be used, 
for example.

Again, I've not really thought it though much, so there are probably 
holes galore in the idea...

-- 

Russ


More information about the Mercurial mailing list