When git checkout -m <path> recreates a conflict, it uses the labels "base", "ours" and "theirs" instead of those of the original merge. Phillip Wood's two-patch series has the ort machinery write the labels to .git/MERGE_LABELS when it switches to a conflicted merge result. checkout -m then reads the file. For git merge and git cherry-pick the labels could be derived from MERGE_HEAD or CHERRY_PICK_HEAD, but git stash pop and git checkout -m <branch> leave no such ref.

Junio Hamano's review asked for a tighter interface. He suggested write_merge_labels() take the repository and the labels[3] array rather than three separate strings, so the caller can pass priv->labels directly. He also noted that the new flag bit does not control whether the file is written, since merge_switch_to_result() writes it unconditionally. It controls whether the file survives cleanup afterwards. He asked whether the file could simply always be left in place.

Wood also asked whether Git should remember the conflict style, so that a merge run with -c merge.conflictStyle=diff3 would be recreated in diff3 style. Hamano said the usual mechanism should decide the style. Recording would only matter when the original merge used a one-shot style differing from the user's usual one, and since checkout -m can be run twice, the user can recover with git -c merge.conflictStyle=diff3 checkout -m <path>.

Wood clarified that he meant only the case where the user gives no style for the checkout, and that --conflict=<style> and -c merge.conflictStyle=<style> would keep working as they do now. Johannes Sixt thought remembering the style would hurt more than help, because he sometimes switches to diff3 with git checkout --conflict=diff3 -m <unmerged-path> and would be disappointed if that stopped working.

The style question is unsettled; the label-recording patches are under review.