{"thread":{"id":"55768","subject":"git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","startedAt":"2021-05-25T07:04:05Z","lastAt":"2021-05-26T22:54:46Z","messageCount":7,"participants":["Bagas Sanjaya","Elijah Newren","Phillip Wood","Igor Djordjevic","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425495","messageId":"79e26cee-daed-d52b-76d7-692f5cb2e20a@gmail.com","threadId":"55768","inReplyTo":null,"subject":"git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-25T07:03:56Z","receivedAt":"2021-05-25T07:04:05Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi,\n\nSupposed that we have following commit graph:\n\n----A----B----C----D <- master\n \\\n ----E <- e\n\nWhen we merge e branch by `git merge e`, obviously we will do 3-way\nmerge. Assumed that the merge doesn't conflict, Git will fire up\neditor to edit `COMMIT_EDITMSG` for us to enter merge commit\nmessage. Then we abort the commit by either delete all the lines\nthere, or comment all of them.\n\nBut when we check status by `git status`, Git says:\n\n> On branch master\n> All conflicts fixed but you are still merging.\n> (use \"git commit\" to conclude merge)\n\nThat message above is misleading, because we know that our merge\ndoesn't conflict (3-way merge applied successfully without conflict). \nHowever, it makes sense only when we have resolved all conflicts\non the conflicted merge.\n\nSo for non-conflicted merge, we can say instead:\n\n> On branch \n> You are still merging, and the merge applied without any conflicts.\n> (use \"git commit\" to conclude merge)\n\nThanks.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"425568","messageId":"CABPp-BHq+=Q6EDNOHJGoUvJsezn=hbQORT=0NRghREf=cnwCYQ@mail.gmail.com","threadId":"55768","inReplyTo":"79e26cee-daed-d52b-76d7-692f5cb2e20a@gmail.com","subject":"Re: git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-05-26T14:30:04Z","receivedAt":"2021-05-26T14:30:20Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya wrote:\n>\n> Hi,\n>\n> Supposed that we have following commit graph:\n>\n> ----A----B----C----D <- master\n> \\\n> ----E <- e\n>\n> When we merge e branch by `git merge e`, obviously we will do 3-way\n> merge. Assumed that the merge doesn't conflict, Git will fire up\n> editor to edit `COMMIT_EDITMSG` for us to enter merge commit\n> message. Then we abort the commit by either delete all the lines\n> there, or comment all of them.\n>\n> But when we check status by `git status`, Git says:\n>\n> > On branch master\n> > All conflicts fixed but you are still merging.\n> > (use \"git commit\" to conclude merge)\n>\n> That message above is misleading, because we know that our merge\n> doesn't conflict (3-way merge applied successfully without conflict).\n> However, it makes sense only when we have resolved all conflicts\n> on the conflicted merge.\n\nOnce upon a time, that message would have always been right. Then a\n--no-commit option was introduced to git merge, and editing of commit\nmessages for merges was also added. As you note, both of those can\nyield cases where the message is misleading/surprising.\n\n> So for non-conflicted merge, we can say instead:\n>\n> > On branch \n> > You are still merging, and the merge applied without any conflicts.\n> > (use \"git commit\" to conclude merge)\n\nAt the time this message is printed, there is no way for us to know\nwhether there had been conflicts. We'd have to record that\ninformation somewhere (probably the index, though introducing another\nindex format just for this seems like a really high lift for such a\nsmall thing, and may conflict with other efforts to extend the index\nformat, such as the sparse-index work), OR re-do the merge when the\nuser runs status just to find out whether there had been conflicts\n(which seems like overkill, and would require you to know which merge\nbackend had been used and with which flags so you could re-check with\nthe same one; further, three of the merge backends -- recursive,\nresolve, and octopus -- all update the working tree and index and thus\ncould not be used for a case like this).\n\nSeems like opening a really big can of worms.\n"},{"id":"425572","messageId":"45c23ea3-0e21-7654-3d2a-5597e159f847@gmail.com","threadId":"55768","inReplyTo":"CABPp-BHq+=Q6EDNOHJGoUvJsezn=hbQORT=0NRghREf=cnwCYQ@mail.gmail.com","subject":"Re: git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-05-26T15:13:18Z","receivedAt":"2021-05-26T15:13:26Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 26/05/2021 15:30, Elijah Newren wrote:\n> On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya wrote:\n>>\n>> Hi,\n>>\n>> Supposed that we have following commit graph:\n>>\n>> ----A----B----C----D <- master\n>> \\\n>> ----E <- e\n>>\n>> When we merge e branch by `git merge e`, obviously we will do 3-way\n>> merge. Assumed that the merge doesn't conflict, Git will fire up\n>> editor to edit `COMMIT_EDITMSG` for us to enter merge commit\n>> message. Then we abort the commit by either delete all the lines\n>> there, or comment all of them.\n>>\n>> But when we check status by `git status`, Git says:\n>>\n>>> On branch master\n>>> All conflicts fixed but you are still merging.\n>>> (use \"git commit\" to conclude merge)\n>>\n>> That message above is misleading, because we know that our merge\n>> doesn't conflict (3-way merge applied successfully without conflict).\n>> However, it makes sense only when we have resolved all conflicts\n>> on the conflicted merge.\n> \n> Once upon a time, that message would have always been right. Then a\n> --no-commit option was introduced to git merge, and editing of commit\n> messages for merges was also added. As you note, both of those can\n> yield cases where the message is misleading/surprising.\n> \n>> So for non-conflicted merge, we can say instead:\n>>\n>>> On branch \n>>> You are still merging, and the merge applied without any conflicts.\n>>> (use \"git commit\" to conclude merge)\n> \n> At the time this message is printed, there is no way for us to know\n> whether there had been conflicts. We'd have to record that\n> information somewhere (probably the index, though introducing another\n> index format just for this seems like a really high lift for such a\n> small thing, and may conflict with other efforts to extend the index\n> format, such as the sparse-index work),\n\nCan we use the information that `git update-index --unresolve` uses to \ntell that there were conflicts? I'm not clear when that data gets \ncleared from the index - if it's not cleared when we commit then it wont \nbe much use for this.\n\nBest Wishes\n\nPhillip\n\n> OR re-do the merge when the\n> user runs status just to find out whether there had been conflicts\n> (which seems like overkill, and would require you to know which merge\n> backend had been used and with which flags so you could re-check with\n> the same one; further, three of the merge backends -- recursive,\n> resolve, and octopus -- all update the working tree and index and thus\n> could not be used for a case like this).\n> \n> Seems like opening a really big can of worms.\n> \n"},{"id":"425575","messageId":"365cecf9-2ce7-9d8d-6898-3234807df963@gmail.com","threadId":"55768","inReplyTo":"CABPp-BHq+=Q6EDNOHJGoUvJsezn=hbQORT=0NRghREf=cnwCYQ@mail.gmail.com","subject":"Re: git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-26T16:06:30Z","receivedAt":"2021-05-26T16:06:43Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 26/05/2021 16:30, Elijah Newren wrote:\n> On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya wrote:\n> >\n> > Hi,\n> >\n> > Supposed that we have following commit graph:\n> >\n> > ----A----B----C----D <- master\n> > \\\n> > ----E <- e\n> >\n> > When we merge e branch by `git merge e`, obviously we will do 3-way\n> > merge. Assumed that the merge doesn't conflict, Git will fire up\n> > editor to edit `COMMIT_EDITMSG` for us to enter merge commit\n> > message. Then we abort the commit by either delete all the lines\n> > there, or comment all of them.\n> >\n> > But when we check status by `git status`, Git says:\n> >\n> > > On branch master\n> > > All conflicts fixed but you are still merging.\n> > > (use \"git commit\" to conclude merge)\n> >\n> > That message above is misleading, because we know that our merge\n> > doesn't conflict (3-way merge applied successfully without conflict).\n> > However, it makes sense only when we have resolved all conflicts\n> > on the conflicted merge.\n> \n> Once upon a time, that message would have always been right. Then a\n> --no-commit option was introduced to git merge, and editing of commit\n> messages for merges was also added. As you note, both of those can\n> yield cases where the message is misleading/surprising.\n> \n> > So for non-conflicted merge, we can say instead:\n> >\n> > > On branch \n> > > You are still merging, and the merge applied without any conflicts.\n> > > (use \"git commit\" to conclude merge)\n> \n> At the time this message is printed, there is no way for us to know\n> whether there had been conflicts. We'd have to record that\n> information somewhere (probably the index, though introducing another\n> index format just for this seems like a really high lift for such a\n> small thing, and may conflict with other efforts to extend the index\n> format, such as the sparse-index work), OR re-do the merge when the\n> user runs status just to find out whether there had been conflicts\n> (which seems like overkill, and would require you to know which merge\n> backend had been used and with which flags so you could re-check with\n> the same one; further, three of the merge backends -- recursive,\n> resolve, and octopus -- all update the working tree and index and thus\n> could not be used for a case like this).\n> \n> Seems like opening a really big can of worms.\n\nAll said, would it be an improvement if current message would be \nsimply reworded to say \"No conflicts but you are still merging\"\n(instead of \"All conflicts fixed but you are still merging\"), thus \nstating the fact (there are no conflicts, indeed) but not implying \nhow we got there (whether conflicts were fixed, or there were none to \nbegin with)...?\n\nRegards, Buga\n"},{"id":"425576","messageId":"CABPp-BF_JkDjXnWnLsYFj0ywpp-r-O7RaqMKFCtQWe8yeJB8Xw@mail.gmail.com","threadId":"55768","inReplyTo":"45c23ea3-0e21-7654-3d2a-5597e159f847@gmail.com","subject":"Re: git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-05-26T16:07:59Z","receivedAt":"2021-05-26T16:08:14Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Phillip,\n\nOn Wed, May 26, 2021 at 8:13 AM Phillip Wood wrote:\n>\n> On 26/05/2021 15:30, Elijah Newren wrote:\n> > On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya wrote:\n> >>\n> >> Hi,\n> >>\n> >> Supposed that we have following commit graph:\n> >>\n> >> ----A----B----C----D <- master\n> >> \\\n> >> ----E <- e\n> >>\n> >> When we merge e branch by `git merge e`, obviously we will do 3-way\n> >> merge. Assumed that the merge doesn't conflict, Git will fire up\n> >> editor to edit `COMMIT_EDITMSG` for us to enter merge commit\n> >> message. Then we abort the commit by either delete all the lines\n> >> there, or comment all of them.\n> >>\n> >> But when we check status by `git status`, Git says:\n> >>\n> >>> On branch master\n> >>> All conflicts fixed but you are still merging.\n> >>> (use \"git commit\" to conclude merge)\n> >>\n> >> That message above is misleading, because we know that our merge\n> >> doesn't conflict (3-way merge applied successfully without conflict).\n> >> However, it makes sense only when we have resolved all conflicts\n> >> on the conflicted merge.\n> >\n> > Once upon a time, that message would have always been right. Then a\n> > --no-commit option was introduced to git merge, and editing of commit\n> > messages for merges was also added. As you note, both of those can\n> > yield cases where the message is misleading/surprising.\n> >\n> >> So for non-conflicted merge, we can say instead:\n> >>\n> >>> On branch \n> >>> You are still merging, and the merge applied without any conflicts.\n> >>> (use \"git commit\" to conclude merge)\n> >\n> > At the time this message is printed, there is no way for us to know\n> > whether there had been conflicts. We'd have to record that\n> > information somewhere (probably the index, though introducing another\n> > index format just for this seems like a really high lift for such a\n> > small thing, and may conflict with other efforts to extend the index\n> > format, such as the sparse-index work),\n>\n> Can we use the information that `git update-index --unresolve` uses to\n> tell that there were conflicts? I'm not clear when that data gets\n> cleared from the index - if it's not cleared when we commit then it wont\n> be much use for this.\n>\n\nWow, I was totally unaware of the resolve-undo extension for the\nindex. Thanks for the pointer. So, it looks like we already _can_\nrecord some kind of specific unmerged information. Perhaps that\ninformation could be used as a proxy for \"were there conflicts\",\nthough I'm still a bit hesitant. Some questions:\n * Can we rely on the extension being written and populated? (does it\nget populated by all relevant codepaths in git?)\n * Even if all codepaths in git will populate it, might the lack of\nthis extension (or its lack of entries) imply that the user used some\nother tool (jgit, something in libgit2, etc.) rather than that there\nwere no conflicts?\n * Can we rely on this for all types of conflicts? For all merge\nbackends? Are there conflict types that don't result in a higher\nstage entry being recorded in the index?\n\nRegarding lack of higher stage entries; some examples of where this\ncould possibly occur (there may be more, I just spent a few minutes\nthinking about it):\n* Files/directories in the working directory in the way of paths you\nwant to write from the merge (merge-recursive will not necessarily\nabort early on these due to renames).\n* \"directory rename split\" -- don't know where to rename individual\nfiles added to old dir because half of old dir went to newdir1 and\nhalf to newdir2\n* A submodule is fast-forwarded by the merge operation, but updating\nthe submodule fails due to its working directory being unclean\n(theoretical; we don't update submodules currently)\n* Would directory/file conflicts (perhaps even combined with\nrename/delete) always result in higher stage entries in the index?\nI'm not sure if they always have historically; it seems likely that\nsome historical merge backends (or current or future external merge\ntools) might yield a conflict without writing a higher stage entry in\nthe index for such a type of conflict.\n* working tree and gitdir on different filesystems; working tree on a\nfull filesystem so we can't write out files even though we wrote out\nnew index and tree and blob objects successfully.\n\nSo, I'd still be more comfortable if we could just record some bit\n\"was_conflicted?\" which gets written. I'd rather not rely on a lack\nof the bit being present to imply a yes or a no.\n\n\nSo, still seems like a can of worms to me.\n"},{"id":"425577","messageId":"CABPp-BHKirQiKB3yWRVN63pVF49DroDkdmD2Q6o+w-BFk5Y=vQ@mail.gmail.com","threadId":"55768","inReplyTo":"365cecf9-2ce7-9d8d-6898-3234807df963@gmail.com","subject":"Re: git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-05-26T16:08:50Z","receivedAt":"2021-05-26T16:09:04Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, May 26, 2021 at 9:06 AM Igor Djordjevic\n wrote:\n>\n> On 26/05/2021 16:30, Elijah Newren wrote:\n> > On Tue, May 25, 2021 at 1:22 AM Bagas Sanjaya wrote:\n> > >\n> > > Hi,\n> > >\n> > > Supposed that we have following commit graph:\n> > >\n> > > ----A----B----C----D <- master\n> > > \\\n> > > ----E <- e\n> > >\n> > > When we merge e branch by `git merge e`, obviously we will do 3-way\n> > > merge. Assumed that the merge doesn't conflict, Git will fire up\n> > > editor to edit `COMMIT_EDITMSG` for us to enter merge commit\n> > > message. Then we abort the commit by either delete all the lines\n> > > there, or comment all of them.\n> > >\n> > > But when we check status by `git status`, Git says:\n> > >\n> > > > On branch master\n> > > > All conflicts fixed but you are still merging.\n> > > > (use \"git commit\" to conclude merge)\n> > >\n> > > That message above is misleading, because we know that our merge\n> > > doesn't conflict (3-way merge applied successfully without conflict).\n> > > However, it makes sense only when we have resolved all conflicts\n> > > on the conflicted merge.\n> >\n> > Once upon a time, that message would have always been right. Then a\n> > --no-commit option was introduced to git merge, and editing of commit\n> > messages for merges was also added. As you note, both of those can\n> > yield cases where the message is misleading/surprising.\n> >\n> > > So for non-conflicted merge, we can say instead:\n> > >\n> > > > On branch \n> > > > You are still merging, and the merge applied without any conflicts.\n> > > > (use \"git commit\" to conclude merge)\n> >\n> > At the time this message is printed, there is no way for us to know\n> > whether there had been conflicts. We'd have to record that\n> > information somewhere (probably the index, though introducing another\n> > index format just for this seems like a really high lift for such a\n> > small thing, and may conflict with other efforts to extend the index\n> > format, such as the sparse-index work), OR re-do the merge when the\n> > user runs status just to find out whether there had been conflicts\n> > (which seems like overkill, and would require you to know which merge\n> > backend had been used and with which flags so you could re-check with\n> > the same one; further, three of the merge backends -- recursive,\n> > resolve, and octopus -- all update the working tree and index and thus\n> > could not be used for a case like this).\n> >\n> > Seems like opening a really big can of worms.\n>\n> All said, would it be an improvement if current message would be\n> simply reworded to say \"No conflicts but you are still merging\"\n> (instead of \"All conflicts fixed but you are still merging\"), thus\n> stating the fact (there are no conflicts, indeed) but not implying\n> how we got there (whether conflicts were fixed, or there were none to\n> begin with)...?\n>\n> Regards, Buga\n\nOoh, now that seems reasonable. Much cleaner solution.\n"},{"id":"425591","messageId":"xmqqeedtayx8.fsf@gitster.g","threadId":"55768","inReplyTo":"CABPp-BF_JkDjXnWnLsYFj0ywpp-r-O7RaqMKFCtQWe8yeJB8Xw@mail.gmail.com","subject":"Re: git status when merging non-conflicted 3-way merge says \"All conflicts fixed\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-26T22:54:43Z","receivedAt":"2021-05-26T22:54:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> * Can we rely on the extension being written and populated? (does it\n> get populated by all relevant codepaths in git?)\n\nThe only place record_resolve_undo() gets called is in the deep guts\nof in-core index manipulation where a conflicted entry is removed\n(either because the resolution decided was to remove the path, or\nthe resolution is about to add the final contents for the path at\nthe stage #0), so yes, as long as you are manipulating the in-core\nindex using our API, you should be recording the action. Otherwise\nwe have a bug, as \"--unresolve\" has to work correctly all the time.\n\n> * Even if all codepaths in git will populate it, might the lack of\n> this extension (or its lack of entries) imply that the user used some\n> other tool (jgit, something in libgit2, etc.) rather than that there\n> were no conflicts?\n\nIt is possible that third-party tools are buggy and corrupt the\non-disk index that way.\n\n> * Can we rely on this for all types of conflicts? For all merge\n> backends? Are there conflict types that don't result in a higher\n> stage entry being recorded in the index?\n\nInteresting thought. I am not confident that the recent \"directory\nrename\" stuff does not break the undo information along that line.\n\nBut at least, the idea is that resolve-undo should be able to\nreproduce the state immediately after any mergy operation stopped\ndue to conflicts by resurrecting the higher stage entries.\n\nBut I do not think \"we had a conflict\" is so black and white to\nbegin with. If you have a rerere record and rerere.autoupdate\nenabled (not recommended), does it mean you didn't have a conflict\nwhen rerere kicks in and you did not have to touch anything to\nresolve it this time, or was there a conflict but it was\nauto-reoslved? I think the \"unresolve\" mechanism should still\nrecord the higher stage entries that gets created first before\nrerere.autoupdate removes them, which matches the latter\ninterpretation that I happen to agree with.\n\nFor that matter, if both sides have made changes to the same file\nnearby, it is more coherent if we declare that there is a conflict\nwhether the changes \"overlap\", as the definition of overlapping is\nfuzzy and depending on the inter-hunk context used during the mergy\noperation, what humans would consider \"close but not overlapping\"\ngets flagged as a \"close enough to warrant manual inspection\"\nconflict (and you can think of rerere as a way to automate that\n'manual inspection' step reusing the prior resolution).\n\nSo I'd vote for \"No conflicts remain, but you haven't committed\",\nwhich would be the most sensible way to phrase the situation.\n"}]}