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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 25, 2017, 20:40 UTC
Message-ID: <xmqqk22wuu5g.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqo9s8uuth.fsf@gitster.mtv.corp.google.com>

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

Show 10 quoted lines

> To populate the database, we'd need a reverse.
> ...
>  * Then the user tells Git that semantic conflicts were resolved and
>    need to be recorded (just like running "git rerere" manually,
>    before "git commit" automatically does it for them these days).
>    This will result in the following:
>
>    - The database is updated so that key <A, B> yields the
>      "merge-fix" commit;
> ...

I probably should have been aiming for stars, as I were outlining the ideal merge-fix logic. The key <A, B> is merely a default, and the worst one at that. There should be a way for the user to tell which exact pair of commits (i.e. another side branch that was merged earlier to the mainline A that renamed 'xyzzy' to 'frotz' wholesale, and the exact commit on the side branch B that added an extra mention of 'xyzzy').

If the logic can figure out what these two commits are without user's help, mechanically by only looking at the merge-fix commit, that would be even better. But I do not believe in miracles, so...