Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2017, 21:01 UTC
Message-ID: <xmqqfudhmw5x.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqeft3u0u5.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> From the user's perspective, calling X "rerere" would probably be OK[1].
>> But from an implementation perspective (and to keep the existing
>> plumbing available and unchanged), it probably makes sense to call it
>> something else, and have it run both rerere and a new plumbing command
>> to do the merge-fix work (or call it nothing, and assume that users will
>> either touch the plumbing directly or will use "git merge" to trigger
>> both).
>> ...
>> I think it should be its own plumbing tool that merge calls alongside
>> rerere. ;)
>
> As long as we use the database keyed with <A,B> and take the merge
> base into account, "git am" and "git cherry-pick" would not be able
> to use the merge-fix machinery, so in that sense, calling X "rerere"
> would not be OK, but I agree with your general sentiment about the
> UI visible to the end users.

Actually, I guess "cherry-pick" could use it if we think hard and long enough and come up with an ideal scheme to compute the index into the merge-fix database.

Imagine this topology:

       A---o---o---...        topic #1
      /
 o---o---o---...              mainline
      \
       o---B---o---C---...    topic #2

where topic #1 renames 'xyzzy' to 'frotz' at commit A, and topic #2 adds a new mention of 'xyzzy' in file F at commit B and another in file E at commit C.

In the ideal world, we would have two merge-fix database entries, one that turns 'xyzzy' in file F to 'frotz' that is keyed by the pair of commits <A,B>, and the other that does the same in file E that is keyed by <A,C>. When merging the topic #1 and the topic #2 together, or when merging the topic #2 to a mainline that already has merged the topic #1, the merge-fix machinery notices that one side has A but not B nor C, and the other side has B and C but not A, and finds these two merge-fixes and applies on top of the textual merge.

If we are cherry-picking C to something that already has A, then, we should be able to notice that the history that receives the cherry-pick has A but not C, and C, which is being picked, does not have A, and decide that merge-fix <A,C> is relevant.

If we do this purely with commit object name, it will still not work if we cherry-pick A to mainline and then we cherry-pick C. The mainline may hae change from A but does not have the exact commit A.

Which brings us back to your earlier idea to use something like patch-id to identify these individual changes. I am not sure how we can structure the merge-fix database so that we can efficiently find which "changes" are already on a branch.