Re: [PATCH 4/5] Documentation: document AUTO_MERGE

From: Philippe Blain <levraiphilippeblain@gmail.com>
Date: Apr 15, 2023, 15:36 UTC
Message-ID: <5cd89e46-f099-24bb-ebe4-fabdd6f94aef@gmail.com>
In-Reply-To: <CABPp-BHyvVhVKa+M-GYTG3OEmgmoaEij15BFXQ6oyDDsboxS9g@mail.gmail.com>

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@gmail.com> wrote:
>>

Thanks for pointing out my typos, those are fixed.

Show 27 quoted lines

>> 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...