On Wed, May 26, 2021 at 9:06 AM Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> wrote: > > On 26/05/2021 16:30, Elijah Newren wrote: > > 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. > > 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 Ooh, now that seems reasonable. Much cleaner solution.
