From: Phillip Wood Date: Wed, 26 May 2021 15:13:18 GMT Subject: Re: git status when merging non-conflicted 3-way merge says "All conflicts fixed" Message-ID: <45c23ea3-0e21-7654-3d2a-5597e159f847@gmail.com> In-Reply-To: On 26/05/2021 15:30, Elijah Newren wrote: > On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya 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 >>> 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), Can we use the information that `git update-index --unresolve` uses to tell that there were conflicts? I'm not clear when that data gets cleared from the index - if it's not cleared when we commit then it wont be much use for this. Best Wishes Phillip > 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. >