git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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.
Previous: Phillip Wood
Message 22 of 22 in “checkout -m: recreate conflict labels”
  1. 0/2 checkout -m: recreate conflict labelsPhillip Wood, Sep 30, 2026
  2. 1/2 remove_branch_state: convert boolean argument to flagsPhillip Wood, Sep 30, 2026
  3. 2/2 merge: remember conflict labelsPhillip Wood, Sep 30, 2026
  4. Junio C HamanoSep 30, 2026
  5. Phillip WoodOct 1, 2026
  6. Junio C HamanoOct 1, 2026
  7. Johannes SixtSep 30, 2026
  8. Junio C HamanoSep 30, 2026
  9. Johannes SixtSep 30, 2026
  10. Phillip WoodOct 1, 2026
  11. 0/2 checkout -m: recreate conflict labelsPhillip Wood, Oct 5, 2026
  12. 1/2 remove_branch_state: convert boolean argument to flagsPhillip Wood, Oct 5, 2026
  13. 2/2 merge: remember conflict labelsPhillip Wood, Oct 5, 2026
  14. Junio C HamanoOct 5, 2026
  15. Phillip WoodOct 6, 2026
  16. Junio C HamanoOct 5, 2026
  17. Phillip WoodOct 6, 2026
  18. Junio C HamanoOct 6, 2026
  19. Phillip WoodOct 7, 2026
  20. Johannes SixtOct 5, 2026
  21. Phillip WoodOct 5, 2026
  22. Junio C HamanoOct 5, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.