Hi Elijah, Le 2023-04-15 à 03:03, Elijah Newren a écrit : > On Fri, Apr 14, 2023 at 10:58 AM Philippe Blain via GitGitGadget > <gitgitgadget@xxxxxxxxx> wrote: >> Thanks for pointing out my typos, those are fixed. >> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt >> index dc9c6a663a9..99e5f652e92 100644 >> --- a/Documentation/user-manual.txt >> +++ b/Documentation/user-manual.txt >> @@ -1343,6 +1343,33 @@ $ git diff -3 file.txt # diff against stage 3 >> $ git diff --theirs file.txt # same as the above. >> ------------------------------------------------- >> >> +When using the 'ort' merge strategy (the default), before updating the working >> +tree with the result of the merge, Git writes a special ref named AUTO_MERGE >> +reflecting the state of the tree it is about to write. Conflicted paths that >> +could not be automatically merged are written to this tree with conflict >> +markers, just as in the working tree. AUTO_MERGE can thus be used with >> +linkgit:git-diff[1] to show the changes you've made so far to resolve >> +conflicts. Using the same example as above, after resolving the conflict we >> +get: > > Mostly... To clarify, conflicted paths *with a textual conflict* are > written with conflict markers. Conflicted paths with non-textual > conflicts are not. There are several conflict types that fall into > the non-textual conflict umbrella: binary files, file/directory, > symlink/directory, symlink/file, modify/delete, rename/add, > rename/delete, rename/rename (1to2), and various submodule and > directory rename conflict types as well. > > The AUTO_MERGE stuff will only help with seeing how textual conflicts > were resolved, it's not much help with the non-textual conflicts. That's true. I think that it might be a good idea to be explicit about "textual conflicts". Although, I think that precision should also be made in the other parts of the doc, not just the user manual, so I'll do that. Thanks, Philippe. > (By contrast, the closely related --remerge-diff option to `git log` > or `git show` does help see the resolution of *both* the textual and > non-textual conflicts, but of course one can't use that option on the > current merge until after first commiting the existing changes.) That's true. And, remerge-diff only helps when actually looking at two-way merge commit, not with conflicts hit during a rebase, cherry-pick or revert. A semi-related trick I use to check conflict resolution during a rebase (after resolving the conflicts but before 'git rebase --continue') is to manually construct a commit from the index and use 'git range-diff' to compare it to REBASE_HEAD. Thinking out loud, maybe a '--check-resolution' flag to the sequencer would make sense to do that automatically...
