Re: [PATCH v2 0/2] checkout -m: recreate conflict labels

[Junio C Hamano <gitster@pobox.com>]

Phillip Wood <phillip.wood123@gmail.com> writes:

> When "git checkout -m <path>" recreates a merge conflict, it uses
> the labels "base", "ours", "theirs", rather than the labels used by
> the original merge. This short series teaches the ort machinery to
> write the labels to ".git/MERGE_LABELS" when it switches to a merge
> result containing conflicts, so that "git checkout -m" can then read
> that file and use the same labels.
>
> As "git checkout -m" is recreating the original conflict I wonder
> if we should remember the conflict style as well so that
>
>     git -c merge.conflictStyle=diff3 git merge topic
>     git checkout -m <unmerged-path>
>
> would recreate diff3 style conflicts, instead of using the default
> config. I cannot decide if that would be convenient or confusing and
> am interested to hear what others think.

It has been quite a while since I invented and last looked at the
code paths for "checkout -m", but we should use the usual mechanism
to decide what conflict style to use, so the only scenario that it
makes difference between recording and not recording is the case you
showed, i.e., the original merge was made with one-shot custom
conflict style that is different from usual.

As "git checkout -m" can be used twice, after the above sequence,
you can

    $ git -c merge.conflictStyle=diff3 checkout -m <path>

to recover without losing any work.  If your regular style is
"merge", then the following sequence might be more commonly useful:

    $ git merge topic
    $ git diff
    ... stare at the diff output, feeling lost trying to
    ... figure out what the correct resolution would be.
    $ git -c merge.conflictStyle=diff3 checkout -m \*
    $ git diff
    ... now with the common ancestor version, you understand
    ... what both sides wanted to do better.