{"thread":{"id":"57130","subject":"Why does \"merge --continue\" expect no arguments?","startedAt":"2021-12-21T14:51:09Z","lastAt":"2021-12-27T19:29:19Z","messageCount":12,"participants":["Daniel Vicarel","Junio C Hamano","Philip Oakley","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"444619","messageId":"CALRdAfcyfesNqfLhhe2GW_5V9s2hf++i6mZS1Lw5hqQYTca85w@mail.gmail.com","threadId":"57130","inReplyTo":null,"subject":"Why does \"merge --continue\" expect no arguments?","fromName":"Daniel Vicarel","fromEmail":"shundra8820@gmail.com","sentAt":"2021-12-21T14:50:56Z","receivedAt":"2021-12-21T14:51:09Z","isPatch":false,"sender":{"key":"shundra8820@gmail.com","avatar":"https://gravatar.com/avatar/3698093e27cd72a51f1e169f80da9ad5da5cdfc29f912e6f3682b1132c2e997a?d=mp&s=160"},"body":"There are several git commands that take a \"--continue\"\noption...`merge`, `rebase`, `cherry-pick`, etc. From looking through\nthe source though, only `merge --continue` seems to expect no other\narguments. Suppose that you have just resolved some merge conflicts,\nand then want to run `git merge --continue --no-edit` to accept the\ndefault merge commit message. Having to open/close the configured text\neditor still is mildly annoying. I'm interested in submitting a patch\nto \"fix\" this `merge` behavior, but I wanted to check if this was\nreally the intended behavior first, and if so why.\n\nThanks,\nDan Vicarel (he/him)\n"},{"id":"444628","messageId":"xmqqlf0dq3t3.fsf@gitster.g","threadId":"57130","inReplyTo":"CALRdAfcyfesNqfLhhe2GW_5V9s2hf++i6mZS1Lw5hqQYTca85w@mail.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-21T17:13:28Z","receivedAt":"2021-12-21T17:13:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Vicarel writes:\n\n> There are several git commands that take a \"--continue\"\n> option...`merge`, `rebase`, `cherry-pick`, etc. From looking through\n> the source though, only `merge --continue` seems to expect no other\n> arguments. Suppose that you have just resolved some merge conflicts,\n> and then want to run `git merge --continue --no-edit` to accept the\n> default merge commit message. Having to open/close the configured text\n> editor still is mildly annoying. I'm interested in submitting a patch\n> to \"fix\" this `merge` behavior, but I wanted to check if this was\n> really the intended behavior first, and if so why.\n\nThe answer lies somewhere between \"it is very much deliberate\" and\n\"'merge --continue' is so unimportant that nobody bothered\".\n\nOriginally, our \"merge\" did not open an editor to give you a chance\nto explain why you are merging a side branch when recording a\ncleanly auto-resolved result. In fact, it didn't even have an\n\"--edit\" option to optionally allow you to edit. This changed at\nf8246281 (merge: use editor by default in interactive sessions,\n2012-01-10); its log message is worth a read to understand the\nissues.\n\nCompared to a merge that cleanly auto-resolved, in a conflicted\nmerge, you have one more thing worth explaining to future readers of\n\"git log\"---how and why the work on the side branch conflicted with\nthe work on the mainline, and how you chose to resolve it.\n\nSo, in that sense, we would very much want to do whatever possible\nto encourage you to write a good log message. Opening an editor is\none step in that direction.\n\nAmong the commands with \"--continue\", \"merge --continue\" came much\nlater, and it did not even need to exist. The other commands with\n\"--continue\", e.g. \"rebase\", deal with multi-step operations, and it\nis worth to have a way to say \"I am finished with this step, let's\nCONTINUE WITH THE REST\". But in \"merge\", there is no remaining\nthing to do after you are done with the conflict you saw.\n\nIn hindsight, we probably should have resisted the urge to add\n\"merge --continue\", just for the sake of misguided \"consistency\"\nperceived on non-existent similarity with other commands that truly\nneed \"--continue\". What is called \"merge --continue\" should have\nbeen called \"merge --finish\", if we needed to add something back\nthen.\n\nThe way to finish a conflicted merge has always been to run \"git\ncommit\" before \"merge --continue\" was added, and it still is not\njust accepted but is the right way to finish a conflicted merge.\n\nSo, in that sense, \"merge --continue\" is so unimportant that it is\nunderstandable that nobody bothered.\n\nSo I guess that makes two discouraging factors against adding\n\"--no-edit\" to \"merge --continue\". It encourages a wrong behaviour\nof under-explaining the result of your work, and \"commit\" is a much\nshorter way to say \"merge --continue\" anyway.\n\nIn fact, \"merge --continue --no-edit\" is much longer to type than\n\"commit --no-edit\".\n\nmerge --continue\ncommit --no-edit\n\nHaving said all that, among various things that the above discussion\nsuggests as possible next steps, i.e.\n\n * deprecate and eventually remove \"merge --continue\"\n * deprecate and eventually rename \"merge --continue\" to \"merge --finish\"\n * add \"--no-edit\" to \"merge --continue\"\n\nI think the last one might be the change with least impact and\nresistance. Those who are unaware that \"commit --no-edit\" suffices\nwould end up typing a lot more and wasting their keyswitches' life,\nbut the damage is limited ;-)\n\nOr we could throw in another\n\n * document more clearly that \"merge --continue\" is a mere synonym\n for, and hint that there is no reason to favor it over, \"git\n commit\".\n\nwhich happens to be my favourite so far after thinking the above\nthrough.\n\nThanks.\n"},{"id":"444631","messageId":"CALRdAffjmvHao8TRfB9YJez1acwHDAq2ZqiqaCRRr5MaWzhxig@mail.gmail.com","threadId":"57130","inReplyTo":"xmqqlf0dq3t3.fsf@gitster.g","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Daniel Vicarel","fromEmail":"shundra8820@gmail.com","sentAt":"2021-12-21T17:51:19Z","receivedAt":"2021-12-21T17:51:32Z","isPatch":false,"sender":{"key":"shundra8820@gmail.com","avatar":"https://gravatar.com/avatar/3698093e27cd72a51f1e169f80da9ad5da5cdfc29f912e6f3682b1132c2e997a?d=mp&s=160"},"body":"Thank you so much for the detailed response! Brief side note...this is\nmy first time posting on the git mailing list (or any mailing list of\nthis kind!), so please educate me if I'm incorrectly quoting, using\nreply/CC, or formatting lines (not sure if the mail server\nautomatically wraps lines after 72 chars)...\n\nJunio C Hamano writes:\n> Compared to a merge that cleanly auto-resolved, in a conflicted\n> merge, you have one more thing worth explaining to future readers of\n> \"git log\"---how and why the work on the side branch conflicted with\n> the work on the mainline, and how you chose to resolve it.\n\nFair point. I would argue that in my own personal projects, where I am\nthe only contributor, sometimes I just want to accept the default\nmerge message and move on. However, one could apply that reasoning to\n_every_ commit message in a personal project, and I certainly don't\nbelieve in that... so yeah, you've given me something to think about.\n\nJunio C Hamano writes:\n> The way to finish a conflicted merge has always been to run \"git\n> commit\" before \"merge --continue\" was added, and it still is not\n> just accepted but is the right way to finish a conflicted merge.\n\nThat makes sense. TBH, I assumed that `merge --continue` _was_ the\npreferred way to finish merging after conflicts simply b/c the option\nexists! `commit --no-edit` definitely meets my immediate needs though,\nso thank you for that suggestion.\n\nJunio C Hamano writes:\n> [...] possible next steps, i.e.\n>\n> * deprecate and eventually remove \"merge --continue\"\n> * deprecate and eventually rename \"merge --continue\" to \"merge --finish\"\n> * add \"--no-edit\" to \"merge --continue\"\n> [...]\n> * document more clearly that \"merge --continue\" is a mere synonym\n> for, and hint that there is no reason to favor it over, \"git\n> commit\".\n\nI agree that some clearer documentation around `merge --continue` is\nworthwhile, to prevent other developers from thinking like myself.\nMaybe a warning from the CLI after running `merge --continue`,\nrecommending `commit` usage instead? Such a warning suggests that the\noption _should_ still be deprecated and removed in the future though.\n\nI am still interested in making a contribution to git, so let me know\nwhich option you would like me to move forward with at this time:\nadding the CLI warning, or going straight to a deprecation. Unless of\ncourse you're already on it. :)\n\n\nOn Tue, Dec 21, 2021 at 12:13 PM Junio C Hamano wrote:\n>\n> Daniel Vicarel writes:\n>\n> > There are several git commands that take a \"--continue\"\n> > option...`merge`, `rebase`, `cherry-pick`, etc. From looking through\n> > the source though, only `merge --continue` seems to expect no other\n> > arguments. Suppose that you have just resolved some merge conflicts,\n> > and then want to run `git merge --continue --no-edit` to accept the\n> > default merge commit message. Having to open/close the configured text\n> > editor still is mildly annoying. I'm interested in submitting a patch\n> > to \"fix\" this `merge` behavior, but I wanted to check if this was\n> > really the intended behavior first, and if so why.\n>\n> The answer lies somewhere between \"it is very much deliberate\" and\n> \"'merge --continue' is so unimportant that nobody bothered\".\n>\n> Originally, our \"merge\" did not open an editor to give you a chance\n> to explain why you are merging a side branch when recording a\n> cleanly auto-resolved result. In fact, it didn't even have an\n> \"--edit\" option to optionally allow you to edit. This changed at\n> f8246281 (merge: use editor by default in interactive sessions,\n> 2012-01-10); its log message is worth a read to understand the\n> issues.\n>\n> Compared to a merge that cleanly auto-resolved, in a conflicted\n> merge, you have one more thing worth explaining to future readers of\n> \"git log\"---how and why the work on the side branch conflicted with\n> the work on the mainline, and how you chose to resolve it.\n>\n> So, in that sense, we would very much want to do whatever possible\n> to encourage you to write a good log message. Opening an editor is\n> one step in that direction.\n>\n> Among the commands with \"--continue\", \"merge --continue\" came much\n> later, and it did not even need to exist. The other commands with\n> \"--continue\", e.g. \"rebase\", deal with multi-step operations, and it\n> is worth to have a way to say \"I am finished with this step, let's\n> CONTINUE WITH THE REST\". But in \"merge\", there is no remaining\n> thing to do after you are done with the conflict you saw.\n>\n> In hindsight, we probably should have resisted the urge to add\n> \"merge --continue\", just for the sake of misguided \"consistency\"\n> perceived on non-existent similarity with other commands that truly\n> need \"--continue\". What is called \"merge --continue\" should have\n> been called \"merge --finish\", if we needed to add something back\n> then.\n>\n> The way to finish a conflicted merge has always been to run \"git\n> commit\" before \"merge --continue\" was added, and it still is not\n> just accepted but is the right way to finish a conflicted merge.\n>\n> So, in that sense, \"merge --continue\" is so unimportant that it is\n> understandable that nobody bothered.\n>\n> So I guess that makes two discouraging factors against adding\n> \"--no-edit\" to \"merge --continue\". It encourages a wrong behaviour\n> of under-explaining the result of your work, and \"commit\" is a much\n> shorter way to say \"merge --continue\" anyway.\n>\n> In fact, \"merge --continue --no-edit\" is much longer to type than\n> \"commit --no-edit\".\n>\n> merge --continue\n> commit --no-edit\n>\n> Having said all that, among various things that the above discussion\n> suggests as possible next steps, i.e.\n>\n> * deprecate and eventually remove \"merge --continue\"\n> * deprecate and eventually rename \"merge --continue\" to \"merge --finish\"\n> * add \"--no-edit\" to \"merge --continue\"\n>\n> I think the last one might be the change with least impact and\n> resistance. Those who are unaware that \"commit --no-edit\" suffices\n> would end up typing a lot more and wasting their keyswitches' life,\n> but the damage is limited ;-)\n>\n> Or we could throw in another\n>\n> * document more clearly that \"merge --continue\" is a mere synonym\n> for, and hint that there is no reason to favor it over, \"git\n> commit\".\n>\n> which happens to be my favourite so far after thinking the above\n> through.\n>\n> Thanks.\n\n\n\n-- \n\nDan Vicarel\n"},{"id":"444633","messageId":"CALRdAffUTf46aU-=_xniKm0NAWE3OTFMFPhXNn669jHcq9dPrg@mail.gmail.com","threadId":"57130","inReplyTo":"CALRdAffjmvHao8TRfB9YJez1acwHDAq2ZqiqaCRRr5MaWzhxig@mail.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Daniel Vicarel","fromEmail":"shundra8820@gmail.com","sentAt":"2021-12-21T17:54:57Z","receivedAt":"2021-12-21T17:55:10Z","isPatch":false,"sender":{"key":"shundra8820@gmail.com","avatar":"https://gravatar.com/avatar/3698093e27cd72a51f1e169f80da9ad5da5cdfc29f912e6f3682b1132c2e997a?d=mp&s=160"},"body":"Eesh, I guess Gmail does top-posting using the entire conversation\nthus far... Apologies for the noise!\n"},{"id":"444635","messageId":"fcdef044-8bec-35b4-431f-40a79ed3c47b@iee.email","threadId":"57130","inReplyTo":"xmqqlf0dq3t3.fsf@gitster.g","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-12-21T17:57:30Z","receivedAt":"2021-12-21T17:57:32Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 21/12/2021 17:13, Junio C Hamano wrote:\n> Or we could throw in another\n>\n> * document more clearly that \"merge --continue\" is a mere synonym\n> for, and hint that there is no reason to favor it over, \"git\n> commit\".\n>\n> which happens to be my favourite so far after thinking the above\n> through.\n>\n> Thanks.\nI'm all for including the \"document more clearly\" approach...\n\nWith or without the code change.\n\n--\nPhilip\n"},{"id":"444748","messageId":"xmqqpmppkvnx.fsf@gitster.g","threadId":"57130","inReplyTo":"CALRdAffjmvHao8TRfB9YJez1acwHDAq2ZqiqaCRRr5MaWzhxig@mail.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-22T06:20:34Z","receivedAt":"2021-12-22T06:20:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Vicarel writes:\n\n> Fair point. I would argue that in my own personal projects, where I am\n> the only contributor, sometimes I just want to accept the default\n> merge message and move on. However, one could apply that reasoning to\n> _every_ commit message in a personal project, and I certainly don't\n> believe in that... so yeah, you've given me something to think about.\n\nLike everybody else, I've had my fair share of \"personal projects\"\nthat I was the only developer who lost interest in them in 6 months\nto 2 years since their inception---after that nobody would care, and\nin such projects, of course, I can remember what I was thinking when\nI did some nonsensical change early in their history. I can survive\nsloppy and crappy messages.\n\nBut in other projects, I've learned that the author of a commit or a\nmerge with my name and e-mail address 6 months ago often is a total\nstranger for me sitting in front of the display right now.\n\n> I agree that some clearer documentation around `merge --continue` is\n> worthwhile, to prevent other developers from thinking like myself.\n> Maybe a warning from the CLI after running `merge --continue`,\n> recommending `commit` usage instead? Such a warning suggests that the\n> option _should_ still be deprecated and removed in the future though.\n>\n> I am still interested in making a contribution to git, so let me know\n> which option you would like me to move forward with at this time:\n> adding the CLI warning, or going straight to a deprecation. Unless of\n> course you're already on it. :)\n\nWelcome to the development community.\n\nIf you want a starter project, among those I listed, perhaps the doc\nupdate would be the quickest one that offers the most to learn from,\nas the first road block new developers seem to stumble on is not\ncoding standard and stuff but social interaction between the patch\nsubmitter and reviewers.\n\nAllowing some selected command line option given to \"git merge\n--continue\" down to underlying \"git commit\" would be a lot harder\nfor somebody new to the codebase. It might make sense to allow\nthings like \"--no-edit\" and \"--no-verify\" to be passed, but you\nwould never ever want to pass something like \"--amend\", or (even\nworse) a pathspec. And coming up with a sensible list of allowed\noptions and arguments would be quite hard.\n\n"},{"id":"444853","messageId":"CALRdAfcKSsct1gD87Pkjugttr3pFbXnh0W=kVa95G+9ZpNtLnA@mail.gmail.com","threadId":"57130","inReplyTo":"CAFOYHZC0r35mfOVUExHsBP5=URKFAt_wDTZ51pTc=XkXyogqKQ@mail.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Daniel Vicarel","fromEmail":"shundra8820@gmail.com","sentAt":"2021-12-23T06:07:56Z","receivedAt":"2021-12-23T06:08:09Z","isPatch":false,"sender":{"key":"shundra8820@gmail.com","avatar":"https://gravatar.com/avatar/3698093e27cd72a51f1e169f80da9ad5da5cdfc29f912e6f3682b1132c2e997a?d=mp&s=160"},"body":"Thanks for the input, all.\n\nJunio C Hamano writes:\n> perhaps the doc update would be the quickest one that offers the most to learn from\n\nSounds good! Now by \"doc update\" do you mean updating docs in the\nDocumentation/ folder, or adding a warning to the CLI output of `git\nmerge --continue`?\n\nJunio C Hamano writes:\n> coming up with a sensible list of allowed options and arguments [to `git merge --continue`] would be quite hard.\n\nChris Packham writes:\n> I think it'd be a good idea to allow [--no-edit on `git merge --continue`] as long as it's the only other option allowed with --continue.\n\nBased on these two pieces of feedback, it sounds like adding _just_\nthe `--no-edit` option at this point to `git merge --continue` is\nworthwhile, and hopefully approachable for a newb. For now I'll put a\npin in it though, and focus on the documentation task above.\n\n\nOn Wed, Dec 22, 2021 at 2:46 AM Chris Packham wrote:\n>\n> Hi Daniel,\n>\n> On Wed, 22 Dec 2021, 2:54 PM Daniel Vicarel, wrote:\n>>\n>> There are several git commands that take a \"--continue\"\n>> option...`merge`, `rebase`, `cherry-pick`, etc. From looking through\n>> the source though, only `merge --continue` seems to expect no other\n>> arguments. Suppose that you have just resolved some merge conflicts,\n>> and then want to run `git merge --continue --no-edit` to accept the\n>> default merge commit message. Having to open/close the configured text\n>> editor still is mildly annoying. I'm interested in submitting a patch\n>> to \"fix\" this `merge` behavior, but I wanted to check if this was\n>> really the intended behavior first, and if so why.\n>\n>\n> I added the --continue option to merge and I can tell you there was no reason --no-edit was omitted, I just didn't think of it at the time. I think it'd be a good idea to allow it as long as it's the only other option allowed with --continue.\n>>\n>>\n>> Thanks,\n>> Dan Vicarel (he/him)\n\n\n\n-- \n\nDan Vicarel\n"},{"id":"444869","messageId":"xmqq1r23cgoo.fsf@gitster.g","threadId":"57130","inReplyTo":"CALRdAfcKSsct1gD87Pkjugttr3pFbXnh0W=kVa95G+9ZpNtLnA@mail.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-23T18:35:51Z","receivedAt":"2021-12-23T18:35:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Vicarel writes:\n\n> Thanks for the input, all.\n>\n> Junio C Hamano writes:\n>> perhaps the doc update would be the quickest one that offers the most to learn from\n>\n> Sounds good! Now by \"doc update\" do you mean updating docs in the\n> Documentation/ folder, or adding a warning to the CLI output of `git\n> merge --continue`?\n\nThe former. The current text says \"... you can conclude the merge\nby running `git merge --continue`\" without giving a clue that this\nis another way to say \"git commit\" that is longer to type.\n\nThe way it rejects extra arguments happens to work as a safety valve\nthat is not very end-user friendly; as you found out, it rejects\noptions and arguments (like pathspec). So \"--continue\" is more than\na mere synonym to \"git commit\".\n\n> Junio C Hamano writes:\n>> coming up with a sensible list of allowed options and arguments [to `git merge --continue`] would be quite hard.\n>\n> Chris Packham writes:\n>> I think it'd be a good idea to allow [--no-edit on `git merge --continue`] as long as it's the only other option allowed with --continue.\n>\n> Based on these two pieces of feedback, it sounds like adding _just_\n> the `--no-edit` option at this point to `git merge --continue` is\n> worthwhile, and hopefully approachable for a newb. For now I'll put a\n> pin in it though, and focus on the documentation task above.\n\nWell, I don't know about Chris, but I didn't mean to suggest that by\nsaying that deciding which ones to allow and which ones to reject is\nhard. Knowing that there are other options that deserve the same\nattention as `--no-edit` to be supported now makes a patch to only\nadd support for `--no-edit` an incomplete one. If we need to add\nsupport for more in the future, at least the mechanism used to add\nthe first one should be something we can reuse in the future for\nthese other ones.\n\nThe way \"git commit\" is internally invoked from \"git merge --continue\"\nhappens to work with the current \"we only pass no arguments, and we\nexit once the command is done\" usage, but it fundamentally is wrong.\nNo cmd_foo() functions should be called from anything but the\nrun_builtin() function in git.c, as they are not prepared to be\ncalled twice, and they are not prepared to be called in an\nenvironment where other things (like reading configuration files)\nhave already happened. If we were to extend what is passed when\n\"git merge --continue\" calls \"git commit\", we should first clean up\nthe (ab)use of cmd_commit() call from the code path, before adding\nnew features.\n\nSo, no, I do not think it is a welcome change to just allow passing\n\"--no-edit\" in a way that is \"approachable for a newb\".\n\nThanks.\n\n\n"},{"id":"444908","messageId":"211224.86mtkqgc8e.gmgdl@evledraar.gmail.com","threadId":"57130","inReplyTo":"xmqqlf0dq3t3.fsf@gitster.g","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-24T17:08:32Z","receivedAt":"2021-12-24T17:10:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Dec 21 2021, Junio C Hamano wrote:\n\n> Or we could throw in another\n>\n> * document more clearly that \"merge --continue\" is a mere synonym\n> for, and hint that there is no reason to favor it over, \"git\n> commit\".\n\nBut it's not:\n\n $ git add foo\n $ git commit -v\n hint: Waiting for your editor to close the file.[...]\n ^C\n $ git merge --continue\n fatal: There is no merge in progress (MERGE_HEAD missing).\n\nFWIW I prefer and use it for that reason, i.e. it's useful for scripting\nto use these \"stateful\" commands when we're in some sort of rebase/merge\n\"sequence\" since it's an extra layer of sanity checking.\n"},{"id":"444935","messageId":"xmqqk0ft5toy.fsf@gitster.g","threadId":"57130","inReplyTo":"211224.86mtkqgc8e.gmgdl@evledraar.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-25T02:01:17Z","receivedAt":"2021-12-25T02:01:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Tue, Dec 21 2021, Junio C Hamano wrote:\n>\n>> Or we could throw in another\n>>\n>> * document more clearly that \"merge --continue\" is a mere synonym\n>> for, and hint that there is no reason to favor it over, \"git\n>> commit\".\n>\n> But it's not:\n>\n> $ git add foo\n> $ git commit -v\n> hint: Waiting for your editor to close the file.[...]\n> ^C\n> $ git merge --continue\n> fatal: There is no merge in progress (MERGE_HEAD missing).\n>\n> FWIW I prefer and use it for that reason, i.e. it's useful for scripting\n> to use these \"stateful\" commands when we're in some sort of rebase/merge\n> \"sequence\" since it's an extra layer of sanity checking.\n\nThere is no additional safety afforded by that, though. There is no\nreason why one would even try to say \"merge --continue\" without\ndoing any merge to begin with.\n\nThe \"merge --continue\" not taking any pathspec is a bit of safety,\nbut even there, \"commit\" already has its own safety to reject\npathspec when it notices that it is concluding a conflicted \"merge\",\nso \"merge --continue\" is not necessary for additional safety there,\neither.\n\n\n\n"},{"id":"444984","messageId":"211227.868rw7exvi.gmgdl@evledraar.gmail.com","threadId":"57130","inReplyTo":"xmqqk0ft5toy.fsf@gitster.g","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-26T23:31:07Z","receivedAt":"2021-12-26T23:43:02Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Dec 24 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Tue, Dec 21 2021, Junio C Hamano wrote:\n>>\n>>> Or we could throw in another\n>>>\n>>> * document more clearly that \"merge --continue\" is a mere synonym\n>>> for, and hint that there is no reason to favor it over, \"git\n>>> commit\".\n>>\n>> But it's not:\n>>\n>> $ git add foo\n>> $ git commit -v\n>> hint: Waiting for your editor to close the file.[...]\n>> ^C\n>> $ git merge --continue\n>> fatal: There is no merge in progress (MERGE_HEAD missing).\n>>\n>> FWIW I prefer and use it for that reason, i.e. it's useful for scripting\n>> to use these \"stateful\" commands when we're in some sort of rebase/merge\n>> \"sequence\" since it's an extra layer of sanity checking.\n>\n> There is no additional safety afforded by that, though. There is no\n> reason why one would even try to say \"merge --continue\" without\n> doing any merge to begin with.\n>\n> The \"merge --continue\" not taking any pathspec is a bit of safety,\n> but even there, \"commit\" already has its own safety to reject\n> pathspec when it notices that it is concluding a conflicted \"merge\",\n> so \"merge --continue\" is not necessary for additional safety there,\n> either.\n\nThe reason would be that you're confused about what state you're in.\n\nI've had that a few times, so I prefer it over \"git commit\", so I daresy\nsomeone less experienced in using git could and would benefit from it as\nwell.\n\nUsually because my \"__git_ps1\" and a subsequent \"git status\" shows one\nstate, so I'll want to continue the merge, but forgot that I did so in\nanother terminal tab already, and the real state of the repository might\nhave moved on to the index being prepared for a non-merge commit.\n\nFor \"rebase --continue\" we change the reflog entry from \"rebase (pick)\"\nto \"rebase (continue)\". Any reason we wouldn't do the same for \"merge\n--continue\"?:\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 5f0476b0b76..51ef8ca36d0 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1358,6 +1358,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tif (!file_exists(git_path_merge_head(the_repository)))\n \t\t\tdie(_(\"There is no merge in progress (MERGE_HEAD missing).\"));\n \n+\t\tstrbuf_addstr(&buf, \"merge (continue)\");\n+\t\tsetenv(\"GIT_REFLOG_ACTION\", buf.buf, 0);\n+\t\tstrbuf_reset(&buf);\n+\n \t\t/* Invoke 'git commit' */\n \t\tret = cmd_commit(nargc, nargv, prefix);\n \t\tgoto done;\ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex c773e30b3fa..7a180f571b7 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -772,6 +772,8 @@ test_expect_success 'completed merge (git merge --continue) with --no-commit and\n \tgit stash show -p MERGE_AUTOSTASH >actual &&\n \ttest_cmp expect actual &&\n \tgit merge --continue 2>err &&\n+\tgit reflog -1 >reflog &&\n+\tgrep -F \"merge (continue)\" reflog &&\n \ttest_i18ngrep \"Applied autostash.\" err &&\n \tgit show HEAD:file >merge-result &&\n \ttest_cmp result.1-5 merge-result &&\n"},{"id":"445010","messageId":"xmqqzgolx2wk.fsf@gitster.g","threadId":"57130","inReplyTo":"211227.868rw7exvi.gmgdl@evledraar.gmail.com","subject":"Re: Why does \"merge --continue\" expect no arguments?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-27T19:29:15Z","receivedAt":"2021-12-27T19:29:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>>> $ git merge --continue\n>>> fatal: There is no merge in progress (MERGE_HEAD missing).\n>>>\n>>> FWIW I prefer and use it for that reason, i.e. it's useful for scripting\n>>> to use these \"stateful\" commands when we're in some sort of rebase/merge\n>>> \"sequence\" since it's an extra layer of sanity checking.\n>>\n>> There is no additional safety afforded by that, though. There is no\n>> reason why one would even try to say \"merge --continue\" without\n>> doing any merge to begin with.\n>>\n>> The \"merge --continue\" not taking any pathspec is a bit of safety,\n>> but even there, \"commit\" already has its own safety to reject\n>> pathspec when it notices that it is concluding a conflicted \"merge\",\n>> so \"merge --continue\" is not necessary for additional safety there,\n>> either.\n>\n> The reason would be that you're confused about what state you're in.\n>\n> I've had that a few times, so I prefer it over \"git commit\", so I daresy\n> someone less experienced in using git could and would benefit from it as\n> well.\n\nOne can be lost and think that one is in the middle of \"git merge\"\nwhen in reality there is no merge going on. Or one can be lost and\nconfused the other way around, i.e. one thinks one is about to\nfinish the work one has been doing and conclude in a single parent\ncommit when in reality that one has done all that is necessary to\nwhip the working tree and the index into a state good enough to\nrecord as a commit object.\n\nIn the former case, saying \"git merge --continue\", instead of \"git\ncommit\" may STOP oneself from proceeding, but then what?\n\nStep back and think the other confusion first. Saying \"git commit\",\ninstead of \"git merge --continue\", would allow one to record the\nmerge commit. It opens an editor, its first line of the log message\nwould say \"Merge blah into bar\", the comment section tells you that\nyou are committing a merge. It even prevents one from making a\npartial commit with \"git commit \" or screw up the state\nwith \"git commit --amend\". It is totally safe.\n\nNow back to the former case. You thought your working tree contents\nand the index was good enough shape to say \"git merge --continue\",\nbut the command refuses because you were not merging. I have a\nsuspicion that the message I am responding is a straw-man not worth\nI should spend more time on, and if you are truly lost you would\neither (1) look at the command line prompt or (2) run \"git status\"\nto re-orient yourself before doing anything drastic like running the\n\"git merge --continue\" command, but hypothetically, if you are lost\nbetween merge and commit yet you are confident enough that your\nworking tree state and the index is worth recording in a commit\nanyway, after a mistaken \"git merge --continue\" stops you from doing\nso, I expect that you would \"git commit\" to record that tree into a\ncommit anyway, no?\n\nSo, I do agree there would be cases where a user is lost and does\nnot know what state the working tree s/he just came back to is in,\nbut \"git merge --continue\" is a mechanism that gives great help to\nsuch a user. \"git status\" may well be such a command, but \"git\nmerge --continue\" is not, and training users to use the latter\ncertainly is a wrong direction to go in.\n\nBy the way, you are wasting your time by repeating what you already\nsaid and given an answer that the line of reasoning does not make\nmuch sense. Unless your goal is to be the one that sends the last\nmessage to a discussion thread, that is. You can respond to this\nmessage without anything new and I promise that I won't repeat what\nhas been said already, in such a case. So you'll be the last one to\nutter in this thread then ;-)\n\nYou can share a new perspective, of course, in which case I may say\n\"Light! thanks\".\n\n\n\n\n"}]}