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

>
> On 26/05/2021 16:30, Elijah Newren wrote:
> > 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.
>
> All said, would it be an improvement if current message would be
> simply reworded to say "No conflicts but you are still merging"
> (instead of "All conflicts fixed but you are still merging"), thus
> stating the fact (there are no conflicts, indeed) but not implying
> how we got there (whether conflicts were fixed, or there were none to
> begin with)...?
>
> Regards, Buga