Re: git status when merging non-conflicted 3-way merge says "All conflicts fixed"

> On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>
>> Hi,
>>
>> Supposed that we have following commit graph:
>>
>> ----A----B----C----D <- master
>>                 \
>>                  ----E <- e
>>
>> When we merge e branch by `git merge e`, obviously we will do 3-way
>> merge. Assumed that the merge doesn't conflict, Git will fire up
>> editor to edit `COMMIT_EDITMSG` for us to enter merge commit
>> message. Then we abort the commit by either delete all the lines
>> there, or comment all of them.
>>
>> But when we check status by `git status`, Git says:
>>
>>> On branch master
>>> All conflicts fixed but you are still merging.
>>>    (use "git commit" to conclude merge)
>>
>> That message above is misleading, because we know that our merge
>> doesn't conflict (3-way merge applied successfully without conflict).
>> However, it makes sense only when we have resolved all conflicts
>> on the conflicted merge.
> 
> Once upon a time, that message would have always been right.  Then a
> --no-commit option was introduced to git merge, and editing of commit
> messages for merges was also added.  As you note, both of those can
> yield cases where the message is misleading/surprising.
> 
>> So for non-conflicted merge, we can say instead:
>>
>>> On branch <branch>
>>> You are still merging, and the merge applied without any conflicts.
>>>    (use "git commit" to conclude merge)
> 
> At the time this message is printed, there is no way for us to know
> whether there had been conflicts.  We'd have to record that
> information somewhere (probably the index, though introducing another
> index format just for this seems like a really high lift for such a
> small thing, and may conflict with other efforts to extend the index
> format, such as the sparse-index work),

> OR re-do the merge when the
> user runs status just to find out whether there had been conflicts
> (which seems like overkill, and would require you to know which merge
> backend had been used and with which flags so you could re-check with
> the same one; further, three of the merge backends -- recursive,
> resolve, and octopus -- all update the working tree and index and thus
> could not be used for a case like this).
> 
> Seems like opening a really big can of worms.
>