[PATCH 2 of 2 evolve-ext] evolve: replace each obsolete sha1 in the description with its latest successor

Matt Harbison matt_harbison at yahoo.com
Sun Aug 10 11:01:10 CDT 2014


Angel Ezquerra wrote:
>
> El 10/08/2014 09:29, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org
> <mailto:pierre-yves.david at ens-lyon.org>> escribió:
>  >
>  >
>  >
>  > On 08/09/2014 09:13 PM, Matt Harbison wrote:
>  >>
>  >> # HG changeset patch
>  >> # User Matt Harbison <matt_harbison at yahoo.com
> <mailto:matt_harbison at yahoo.com>>
>  >> # Date 1407625936 14400
>  >> #      Sat Aug 09 19:12:16 2014 -0400
>  >> # Node ID 6e20d95da8ace63e621f63a59d8b1426e227eaee
>  >> # Parent  66f4c5c52d970f145cd218ceed065c3fe096631d
>  >> evolve: replace each obsolete sha1 in the description with its
> latest successor
>  >
>  >
>  > The feature looks awesome. Thanks. I've some feedback on the
> implementation.
>  >
>
> I agree, this is just awesome.
>
> It would be really really cool if we did the same for the tags that
> refer to obsolete changesets. Amending tagged revisions is annoying.
>
> Cheers,
>
> Angel
>

I agree.  And then I went to tag what I submitted here, and realized 
that the tag would move as I evolved things, which would defeat the 
point of tagging it.  So maybe we should evolve global tags only. 
(Though I'm in the habit of only creating global tags without thinking, 
and probably others are too.)  Would it be too surprising if local tags 
didn't evolve and global tags did?  I can see the use for evolving local 
tags in some cases too though.  I don't want a command line switch for this.

It seems that the cset copy (as opposed to the finalization where I 
handled the message update) is in rebase.rebasenode(), and it looks like 
the majority of the work is actually in merge.update().  I don't know 
how to change that without affecting non-evolve related updates.  (I 
suppose the alternative is to do it in evolve.relocate() after 
cmdutil.duplicatecopies() and patch up dirstate if necessary).  I have 
long thought it would be nice if rebase itself handled updating tags and 
commit messages as it processed the series, but never quite figured out 
how to do that.  Evolution probably makes that moot now.

What if you have a cset with a tag file that adds 'Y' to .hgtags that 
already contains 'X'.  When you evolve that single tag commit adding 
'Y', if 'X' and 'Y' are obsolete, do you evolve both entries in the 
file?  That can probably only happen if you tag 'X' on a different 
branch, and I'm not sure how common that is.

I'm not sure that there will be enough content to justify breaking the 
translation of obsolete -> successor hash into a utility function to 
share between the message and tag update cases.  So do you want to try 
your hand at the tag updates?  You're probably more familiar with the 
tag file than me with the merge work you did recently.

--Matt


More information about the Mercurial-devel mailing list