Re: [PATCH v2 0/2] checkout -m: recreate conflict labels
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 5, 2026, 15:53 UTC
- Message-ID
- <xmqqcxtom9e0.fsf@gitster.g>
- In-Reply-To
- <cover.1791206658.git.phillip.wood@dunelm.org.uk>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 16 quoted lines
> 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.