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

[Matt Harbison]

Pierre-Yves David wrote:
>
>
> 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)

I agree with the global tag part.  I'd like global tags to remain 
mutable, because there have been a couple of times where I've tagged 
something and then found I've needed to tweak something before the build 
itself goes public.  So it's convenient, though I understand the other 
side too.

I don't necessarily like what you suggest for local though, because I 
can't prevent it from moving when I don't want it to in the scenario 
described above.  I'll probably skip it for the first implementation anyway.

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

OK, agreed.  Should I *replace* the obsolete entry in .hgtags, or just 
append the new one on to the end?  I would think you would want to 
replace it so that the dangling reference isn't there in the public repo 
for all time.  But I ran into a case the other day where I obsoleted a 
commit that created a tag, and then tagged something else with the same 
label.  That 'tag something else' commit added entries for both tags in 
a single commit, even though the original was off in its own extinct 
branch.  I know moving tags causes several entries to be added, but this 
didn't require a --force.  I couldn't tell if that was by design or a 
bug, but I realized I don't understand some of the tradeoffs made to 
track tags in a file.

(I can try to reproduce this if you think it is a bug.)

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