[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