On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya <bagasdotme@xxxxxxxxx> 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.
