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

[Pierre-Yves David]

On 08/10/2014 05:01 PM, Matt Harbison wrote:

This message apparently feel into a crack of my inbox, sorry about that.

> 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.

We should probably have different strategy here.

Updating global tags in all case seems a pure win. Even if I'm sometimes 
considering that adding a global tags should maybe turn stuff 
public//immutable.

Local tag should behave like bookmark. Whenever we obsolete something we 
move all relevants information to the successors (working copy parent, 
bookmark) local tag should go in that list (in my opinions)

> 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.

The evolve implementation is hacky and most of these part was done 3 
year ago by a newbie me. Feel free to refactor//improve anything there.

> 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.

Touching only the entry one commit adds sounds more sensible.

> 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.

Yes it make sense.


-- 
Pierre-Yves David