{"thread":{"id":"44888","subject":"[RFC] stash --continue","startedAt":"2017-01-15T23:56:09Z","lastAt":"2017-01-20T15:33:52Z","messageCount":16,"participants":["Stephan Beyer","Jacob Keller","Johannes Schindelin","Junio C Hamano","Marc Branchaud","Samuel Lijin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309459","messageId":"cd784a4e-ee99-564e-81de-9f7f6cc26c67@gmx.net","threadId":"44888","inReplyTo":null,"subject":"[RFC] stash --continue","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2017-01-15T23:56:00Z","receivedAt":"2017-01-15T23:56:09Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\na git-newbie-ish co-worker uses git-stash sometimes. Last time he used\n\"git stash pop\", he got into a merge conflict. After he resolved the\nconflict, he did not know what to do to get the repository into the\nwanted state. In his case, it was only \"git add <resolved files>\"\nfollowed by a \"git reset\" and a \"git stash drop\", but there may be more\ninvolved cases when your index is not clean before \"git stash pop\" and\nyou want to have your index as before.\n\nThis led to the idea to have something like \"git stash --continue\"[1]\nthat would expect the user to \"git add\" the resolved files (as \"git\nstatus\" suggests) but then leads to the expected result, i.e. the index\nbeing the same as before the conflict, the stash being dropped (if \"pop\"\nwas used instead of \"apply\"), etc.\n\nLikewise, some \"git stash --abort\"[2] might be useful in case you did\n\"git stash pop\" with the wrong stash in mind.\n\nWhat do you think about that?\n\nAlthough I think this would be a nice-to-have feature, I am not totally\nsure how to achieve backwards-compatibility, i.e., such that using\n--continue is still optional... (I think that \"git stash apply\" would\nsurely generate auxiliary data in case of a conflict and --continue or\n--abort would remove it...)\n\nBest\n  Stephan\n\nFootnotes\n1. Perhaps with a better name, because it does not really continue.\nMaybe a \"git stash conflict [--resolved]\" subcommand?\n2. Along the lines of [1], one could use \"git stash conflict --abort\"?\n"},{"id":"309466","messageId":"CA+P7+xpSRD946UUGdf2Dn+FGDMrTgON7t_WMdQS8z4ReNMZrVg@mail.gmail.com","threadId":"44888","inReplyTo":"cd784a4e-ee99-564e-81de-9f7f6cc26c67@gmx.net","subject":"Re: [RFC] stash --continue","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-01-16T03:59:40Z","receivedAt":"2017-01-16T04:00:09Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Jan 15, 2017 at 3:56 PM, Stephan Beyer <s-beyer@gmx.net> wrote:\n> Hi,\n>\n> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used\n> \"git stash pop\", he got into a merge conflict. After he resolved the\n> conflict, he did not know what to do to get the repository into the\n> wanted state. In his case, it was only \"git add <resolved files>\"\n> followed by a \"git reset\" and a \"git stash drop\", but there may be more\n> involved cases when your index is not clean before \"git stash pop\" and\n> you want to have your index as before.\n>\n> This led to the idea to have something like \"git stash --continue\"[1]\n> that would expect the user to \"git add\" the resolved files (as \"git\n> status\" suggests) but then leads to the expected result, i.e. the index\n> being the same as before the conflict, the stash being dropped (if \"pop\"\n> was used instead of \"apply\"), etc.\n>\n> Likewise, some \"git stash --abort\"[2] might be useful in case you did\n> \"git stash pop\" with the wrong stash in mind.\n>\n> What do you think about that?\n>\n\nThis sounds like a useful extension to me.\n\nThanks,\nJake\n"},{"id":"309480","messageId":"alpine.DEB.2.20.1701161153340.3469@virtualbox","threadId":"44888","inReplyTo":"cd784a4e-ee99-564e-81de-9f7f6cc26c67@gmx.net","subject":"Re: [RFC] stash --continue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-16T10:54:04Z","receivedAt":"2017-01-16T10:54:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stephan,\n\nOn Mon, 16 Jan 2017, Stephan Beyer wrote:\n\n> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used\n> \"git stash pop\", he got into a merge conflict. After he resolved the\n> conflict, he did not know what to do to get the repository into the\n> wanted state. In his case, it was only \"git add <resolved files>\"\n> followed by a \"git reset\" and a \"git stash drop\", but there may be more\n> involved cases when your index is not clean before \"git stash pop\" and\n> you want to have your index as before.\n> \n> This led to the idea to have something like \"git stash --continue\"[1]\n\nMore like \"git stash pop --continue\". Without the \"pop\" command, it does\nnot make too much sense.\n\nCiao,\nJohannes\n"},{"id":"309546","messageId":"xmqqy3y9e8uh.fsf@gitster.mtv.corp.google.com","threadId":"44888","inReplyTo":"cd784a4e-ee99-564e-81de-9f7f6cc26c67@gmx.net","subject":"Re: [RFC] stash --continue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-17T20:21:10Z","receivedAt":"2017-01-17T20:26:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephan Beyer <s-beyer@gmx.net> writes:\n\n> This led to the idea to have something like \"git stash --continue\"[1]\n> that would expect the user to \"git add\" the resolved files (as \"git\n> status\" suggests) but then leads to the expected result, i.e. the index\n> being the same as before the conflict, the stash being dropped (if \"pop\"\n> was used instead of \"apply\"), etc.\n>\n> Likewise, some \"git stash --abort\"[2] might be useful in case you did\n> \"git stash pop\" with the wrong stash in mind.\n>\n> What do you think about that?\n\n\"git stash pop --continue\" (and \"git stash apply --continue\") would\nmake quite a lot of sense.  I like it very much primarily because it\nwill give us an opportunity to correct a major UI glitches around\napplying stashed changes to the working tree.\n\nDon't people find it strange that \"stash pop\" that applies cleanly\nwould not touch the index, leaving (an equivalent of) the changes\nstashed earlier floating in the working tree, but \"stash pop\" that\nconflicts and needs a three-way merge touches the index and the\nusual way of concluding the manual conflict resolution is \"git add\"\nthe paths, meaning that the changes that were not ready hence\nfloating in the working tree back when the stash was made goes into\nthe index when the user concludes \"stash pop\"?\n\nWith an explicit \"--continue\", we can fix that so that we reset the\nindex to the HEAD.  That way, whether the changes have conflict with\nthe HEAD's tree or not, the end user after \"stash pop\" will see the\nchanges in the working tree and \"git diff\" (no HEAD argument or\n\"--cached\" option) will consistently show what came from the stash.\n"},{"id":"309629","messageId":"d5456165-bdf2-e9e7-117f-aeab0ff4b417@xiplink.com","threadId":"44888","inReplyTo":"alpine.DEB.2.20.1701161153340.3469@virtualbox","subject":"Re: [RFC] stash --continue","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2017-01-18T15:41:00Z","receivedAt":"2017-01-18T15:51:49Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n> Hi Stephan,\n>\n> On Mon, 16 Jan 2017, Stephan Beyer wrote:\n>\n>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used\n>> \"git stash pop\", he got into a merge conflict. After he resolved the\n>> conflict, he did not know what to do to get the repository into the\n>> wanted state. In his case, it was only \"git add <resolved files>\"\n>> followed by a \"git reset\" and a \"git stash drop\", but there may be more\n>> involved cases when your index is not clean before \"git stash pop\" and\n>> you want to have your index as before.\n>>\n>> This led to the idea to have something like \"git stash --continue\"[1]\n>\n> More like \"git stash pop --continue\". Without the \"pop\" command, it does\n> not make too much sense.\n\nWhy not?  git should be able to remember what stash command created the \nconflict.  Why should I have to?  Maybe the fire alarm goes off right \nwhen I run the stash command, and by the time I get back to it I can't \nremember which operation I did.  It would be nice to be able to tell git \nto \"just finish off (or abort) the stash operation, whatever it was\".\n\n\t\tM.\n\n"},{"id":"309631","messageId":"alpine.DEB.2.20.1701181725130.3469@virtualbox","threadId":"44888","inReplyTo":"d5456165-bdf2-e9e7-117f-aeab0ff4b417@xiplink.com","subject":"Re: [RFC] stash --continue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-18T16:34:58Z","receivedAt":"2017-01-18T16:35:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Marc,\n\nOn Wed, 18 Jan 2017, Marc Branchaud wrote:\n\n> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n>\n> > On Mon, 16 Jan 2017, Stephan Beyer wrote:\n> >\n> > > a git-newbie-ish co-worker uses git-stash sometimes. Last time he\n> > > used \"git stash pop\", he got into a merge conflict. After he\n> > > resolved the conflict, he did not know what to do to get the\n> > > repository into the wanted state. In his case, it was only \"git add\n> > > <resolved files>\" followed by a \"git reset\" and a \"git stash drop\",\n> > > but there may be more involved cases when your index is not clean\n> > > before \"git stash pop\" and you want to have your index as before.\n> > >\n> > > This led to the idea to have something like \"git stash\n> > > --continue\"[1]\n> >\n> > More like \"git stash pop --continue\". Without the \"pop\" command, it\n> > does not make too much sense.\n> \n> Why not?  git should be able to remember what stash command created the\n> conflict.  Why should I have to?  Maybe the fire alarm goes off right when I\n> run the stash command, and by the time I get back to it I can't remember\n> which operation I did.  It would be nice to be able to tell git to \"just\n> finish off (or abort) the stash operation, whatever it was\".\n\nThat reeks of a big potential for confusion.\n\nImagine for example a total Git noob who calls `git stash list`, scrolls\ntwo pages down, then hits `q` by mistake. How would you explain to that\nuser that `git stash --continue` does not continue showing the list at the\nthird page?\n\nEven worse: `git stash` (without arguments) defaults to the `save`\noperation, so any user who does not read the documentation (and who does?)\nwould assume that `git stash --continue` *also* implies `save`.\n\nIf that was not enough, there would still be the overall design of Git's\nuser interface. You can call it confusing, inconsistent, with a lot of\nroom for improvement, and you would be correct. But none of Git's commands\nhas a `--continue` option that remembers the latest subcommand and\ncontinues that. To introduce that behavior in `git stash` would disimprove\nthe situation.\n\nWith every new feature, it is not enough to consider its benefits. You\nalways have to take the potential fallout into account, too.\n\nAt least `git stash pop --continue` would be consistent with all other\n`--continue` options in Git that I can think of...\n\nCiao,\nJohannes\n"},{"id":"309641","messageId":"38d592b8-975c-1fd9-4c42-877e34a4ab70@xiplink.com","threadId":"44888","inReplyTo":"alpine.DEB.2.20.1701181725130.3469@virtualbox","subject":"Re: [RFC] stash --continue","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2017-01-18T18:44:08Z","receivedAt":"2017-01-18T18:51:54Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 2017-01-18 11:34 AM, Johannes Schindelin wrote:\n> Hi Marc,\n>\n> On Wed, 18 Jan 2017, Marc Branchaud wrote:\n>\n>> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n>>\n>>> On Mon, 16 Jan 2017, Stephan Beyer wrote:\n>>>\n>>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he\n>>>> used \"git stash pop\", he got into a merge conflict. After he\n>>>> resolved the conflict, he did not know what to do to get the\n>>>> repository into the wanted state. In his case, it was only \"git add\n>>>> <resolved files>\" followed by a \"git reset\" and a \"git stash drop\",\n>>>> but there may be more involved cases when your index is not clean\n>>>> before \"git stash pop\" and you want to have your index as before.\n>>>>\n>>>> This led to the idea to have something like \"git stash\n>>>> --continue\"[1]\n>>>\n>>> More like \"git stash pop --continue\". Without the \"pop\" command, it\n>>> does not make too much sense.\n>>\n>> Why not?  git should be able to remember what stash command created the\n>> conflict.  Why should I have to?  Maybe the fire alarm goes off right when I\n>> run the stash command, and by the time I get back to it I can't remember\n>> which operation I did.  It would be nice to be able to tell git to \"just\n>> finish off (or abort) the stash operation, whatever it was\".\n>\n> That reeks of a big potential for confusion.\n>\n> Imagine for example a total Git noob who calls `git stash list`, scrolls\n> two pages down, then hits `q` by mistake. How would you explain to that\n> user that `git stash --continue` does not continue showing the list at the\n> third page?\n\nSorry, but I have trouble taking that example seriously.  It assumes \nsuch a level of \"noobness\" that the user doesn't even understand how \nstandard command output paging works, not just with git but with any \nshell command.\n\n> Even worse: `git stash` (without arguments) defaults to the `save`\n> operation, so any user who does not read the documentation (and who does?)\n> would assume that `git stash --continue` *also* implies `save`.\n\nLike the first example, your user is trying to \"continue\" a command that \nis already complete.  It's like try to do \"git rebase --continue\" when \nthere's no rebase operation underway.\n\nNow, maybe there is some way for \"git stash save\" (implied or explicit) \nto stop partway through the operation.  I can't imagine such a situation \n(out of disk space, maybe?), particularly where the user would expect \n\"git stash save\" to leave things in a half-finished state.  To me \"git \nstash save\" should be essentially all-or-nothing.\n\nHowever, if there were such a partial-failure scenario, then I think it \nwould be perfectly reasonable for \"git stash --continue\" to finish the \nsave operation, assuming that the failure condition has been resolved.\n\n> If that was not enough, there would still be the overall design of Git's\n> user interface. You can call it confusing, inconsistent, with a lot of\n> room for improvement, and you would be correct. But none of Git's commands\n> has a `--continue` option that remembers the latest subcommand and\n> continues that. To introduce that behavior in `git stash` would disimprove\n> the situation.\n\nI think it's more the case that none of the current continuable commands \nhave subcommands (though I can't think of all the continuable or \nabortable operations offhand, so maybe I'm wrong).  I think we're \ndiscussing new UI ground here.\n\nAnd since the pattern is already \"git foo --continue\", it seems more \nconsistent to me for it to be \"git stash --continue\" as well. \nEspecially since there can be only one partially-complete stash \nsub-operation at one time (per workdir, at least).  So there's no reason \nto change the pattern just for the stash command.\n\nThink of it this way:  All the currently continuable/abortable commands \nput the repository in a shaky state, where performing certain other \noperations would be ill advised.  Attempting to start a rebase while a \nmerge conflict is unresolved, for example.  IIRC, git actually tries to \nstop users from shooting their feet in this way.\n\nAnd so it should be for the stash operation:  If applying a stash yields \na conflict, it has to be resolved or aborted before something like a \nrebase or merge is attempted.  It doesn't matter which stash subcommand \ncreated the shaky situation.\n\nIn the long run, I think there's even the possibility of generic \"git \ncontinue\" and \"git abort\" commands, that simply continue or abort the \ncurrent partially-complete operation, whatever it is.  (Isn't that the \nultimate goal of all the \"sequencer\" work?  I admit I have not been \nfollowing that effort.)\n\n> With every new feature, it is not enough to consider its benefits. You\n> always have to take the potential fallout into account, too.\n\nAgreed.\n\n> At least `git stash pop --continue` would be consistent with all other\n> `--continue` options in Git that I can think of...\n\nAlas, I disagree!\n\n\t\tM.\n\n"},{"id":"309645","messageId":"xmqqk29s9oby.fsf@gitster.mtv.corp.google.com","threadId":"44888","inReplyTo":"alpine.DEB.2.20.1701181725130.3469@virtualbox","subject":"Re: [RFC] stash --continue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-18T19:10:09Z","receivedAt":"2017-01-18T19:10:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> > More like \"git stash pop --continue\". Without the \"pop\" command, it\n>> > does not make too much sense.\n>> \n>> Why not?  git should be able to remember what stash command created the\n>> conflict.  Why should I have to?  Maybe the fire alarm goes off right when I\n>> run the stash command, and by the time I get back to it I can't remember\n>> which operation I did.  It would be nice to be able to tell git to \"just\n>> finish off (or abort) the stash operation, whatever it was\".\n>\n> That reeks of a big potential for confusion.\n\nYup.  I agree everything you said in the message I am responding\nto.  Marc's argument will inevitably lead to: It should be\nsufficient to say \"git --continue\", as Git should remember\neverything for me.  I do not think we want to go there.\n"},{"id":"309649","messageId":"e273c7c8-278a-061c-44fd-4808b53d0475@gmx.net","threadId":"44888","inReplyTo":"d5456165-bdf2-e9e7-117f-aeab0ff4b417@xiplink.com","subject":"Re: [RFC] stash --continue","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2017-01-18T19:20:37Z","receivedAt":"2017-01-18T19:22:42Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nOn 01/18/2017 04:41 PM, Marc Branchaud wrote:\n> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n>> On Mon, 16 Jan 2017, Stephan Beyer wrote:\n>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used\n>>> \"git stash pop\", he got into a merge conflict. After he resolved the\n>>> conflict, he did not know what to do to get the repository into the\n>>> wanted state. In his case, it was only \"git add <resolved files>\"\n>>> followed by a \"git reset\" and a \"git stash drop\", but there may be more\n>>> involved cases when your index is not clean before \"git stash pop\" and\n>>> you want to have your index as before.\n>>>\n>>> This led to the idea to have something like \"git stash --continue\"[1]\n>>\n>> More like \"git stash pop --continue\". Without the \"pop\" command, it does\n>> not make too much sense.\n> \n> Why not?  git should be able to remember what stash command created the\n> conflict.  Why should I have to?\n\nDscho and Junio gave you a git-perspective argument.\nI give you a user-perspective one:\nWhat if you did \"git stash pop\" and ran into an (unexpected) conflict.\nYou resolve it, and you probably - for some reason - don't want to drop\nthe stash now, as \"git stash --continue\" (assuming \"pop\") would do. So\nI'd regard it as a feature if you could now run \"git stash apply\n--continue\" to just finish the job without dropping.\n\nBest\nStephan\n\nPS: I put this idea in my todo priority queue. If somebody else is\ninterested: I am not going to work at this idea before February.\n\nPPS: Any opinions about the mentioned \"backwards-compatibility\" issue\nthat people are then forced to finish their commits with \"--continue\"\ninstead of \"git reset\" or \"git commit\"?\n"},{"id":"309651","messageId":"CAJZjrdXwNFaZFP-asVB9kXUFp1TfRr5w1O+opVRFzxV-qQmpRg@mail.gmail.com","threadId":"44888","inReplyTo":"38d592b8-975c-1fd9-4c42-877e34a4ab70@xiplink.com","subject":"Re: [RFC] stash --continue","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-01-18T19:35:16Z","receivedAt":"2017-01-18T19:43:43Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":">> At least `git stash pop --continue` would be consistent with all other\n>> `--continue` options in Git that I can think of...\n\n> Alas, I disagree!\n\nI'm with Johannes here. \"git stash\" sans subcommand is pretty\nexplicitly defined as \"git stash save\", so by similar logic, \"git\nstash --continue\", if anything, would be \"git stash save --continue\".\n\nI do agree that there's a slight problem with hunting down consistency\nin implementations of --continue since there aren't other usages that\ninvolve subcommands (rebase, cp, merge) but I can't think of \"git\nstash\" as a completely specified command, whereas I do see \"git stash\npop\" and \"git stash apply\" as completely specified.\n\nOn Wed, Jan 18, 2017 at 12:44 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:\n> On 2017-01-18 11:34 AM, Johannes Schindelin wrote:\n>>\n>> Hi Marc,\n>>\n>> On Wed, 18 Jan 2017, Marc Branchaud wrote:\n>>\n>>> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n>>>\n>>>> On Mon, 16 Jan 2017, Stephan Beyer wrote:\n>>>>\n>>>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he\n>>>>> used \"git stash pop\", he got into a merge conflict. After he\n>>>>> resolved the conflict, he did not know what to do to get the\n>>>>> repository into the wanted state. In his case, it was only \"git add\n>>>>> <resolved files>\" followed by a \"git reset\" and a \"git stash drop\",\n>>>>> but there may be more involved cases when your index is not clean\n>>>>> before \"git stash pop\" and you want to have your index as before.\n>>>>>\n>>>>> This led to the idea to have something like \"git stash\n>>>>> --continue\"[1]\n>>>>\n>>>>\n>>>> More like \"git stash pop --continue\". Without the \"pop\" command, it\n>>>> does not make too much sense.\n>>>\n>>>\n>>> Why not?  git should be able to remember what stash command created the\n>>> conflict.  Why should I have to?  Maybe the fire alarm goes off right\n>>> when I\n>>> run the stash command, and by the time I get back to it I can't remember\n>>> which operation I did.  It would be nice to be able to tell git to \"just\n>>> finish off (or abort) the stash operation, whatever it was\".\n>>\n>>\n>> That reeks of a big potential for confusion.\n>>\n>> Imagine for example a total Git noob who calls `git stash list`, scrolls\n>> two pages down, then hits `q` by mistake. How would you explain to that\n>> user that `git stash --continue` does not continue showing the list at the\n>> third page?\n>\n>\n> Sorry, but I have trouble taking that example seriously.  It assumes such a\n> level of \"noobness\" that the user doesn't even understand how standard\n> command output paging works, not just with git but with any shell command.\n>\n>> Even worse: `git stash` (without arguments) defaults to the `save`\n>> operation, so any user who does not read the documentation (and who does?)\n>> would assume that `git stash --continue` *also* implies `save`.\n>\n>\n> Like the first example, your user is trying to \"continue\" a command that is\n> already complete.  It's like try to do \"git rebase --continue\" when there's\n> no rebase operation underway.\n>\n> Now, maybe there is some way for \"git stash save\" (implied or explicit) to\n> stop partway through the operation.  I can't imagine such a situation (out\n> of disk space, maybe?), particularly where the user would expect \"git stash\n> save\" to leave things in a half-finished state.  To me \"git stash save\"\n> should be essentially all-or-nothing.\n>\n> However, if there were such a partial-failure scenario, then I think it\n> would be perfectly reasonable for \"git stash --continue\" to finish the save\n> operation, assuming that the failure condition has been resolved.\n>\n>> If that was not enough, there would still be the overall design of Git's\n>> user interface. You can call it confusing, inconsistent, with a lot of\n>> room for improvement, and you would be correct. But none of Git's commands\n>> has a `--continue` option that remembers the latest subcommand and\n>> continues that. To introduce that behavior in `git stash` would disimprove\n>> the situation.\n>\n>\n> I think it's more the case that none of the current continuable commands\n> have subcommands (though I can't think of all the continuable or abortable\n> operations offhand, so maybe I'm wrong).  I think we're discussing new UI\n> ground here.\n>\n> And since the pattern is already \"git foo --continue\", it seems more\n> consistent to me for it to be \"git stash --continue\" as well. Especially\n> since there can be only one partially-complete stash sub-operation at one\n> time (per workdir, at least).  So there's no reason to change the pattern\n> just for the stash command.\n>\n> Think of it this way:  All the currently continuable/abortable commands put\n> the repository in a shaky state, where performing certain other operations\n> would be ill advised.  Attempting to start a rebase while a merge conflict\n> is unresolved, for example.  IIRC, git actually tries to stop users from\n> shooting their feet in this way.\n>\n> And so it should be for the stash operation:  If applying a stash yields a\n> conflict, it has to be resolved or aborted before something like a rebase or\n> merge is attempted.  It doesn't matter which stash subcommand created the\n> shaky situation.\n>\n> In the long run, I think there's even the possibility of generic \"git\n> continue\" and \"git abort\" commands, that simply continue or abort the\n> current partially-complete operation, whatever it is.  (Isn't that the\n> ultimate goal of all the \"sequencer\" work?  I admit I have not been\n> following that effort.)\n>\n>> With every new feature, it is not enough to consider its benefits. You\n>> always have to take the potential fallout into account, too.\n>\n>\n> Agreed.\n>\n>> At least `git stash pop --continue` would be consistent with all other\n>> `--continue` options in Git that I can think of...\n>\n>\n> Alas, I disagree!\n>\n>                 M.\n>\n"},{"id":"309730","messageId":"alpine.DEB.2.20.1701191341530.3469@virtualbox","threadId":"44888","inReplyTo":"38d592b8-975c-1fd9-4c42-877e34a4ab70@xiplink.com","subject":"Re: [RFC] stash --continue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-19T15:49:16Z","receivedAt":"2017-01-19T15:49:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Marc,\n\nOn Wed, 18 Jan 2017, Marc Branchaud wrote:\n\n> On 2017-01-18 11:34 AM, Johannes Schindelin wrote:\n> >\n> > On Wed, 18 Jan 2017, Marc Branchaud wrote:\n> >\n> > > On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n> > >\n> > > > On Mon, 16 Jan 2017, Stephan Beyer wrote:\n> > > >\n> > > > > a git-newbie-ish co-worker uses git-stash sometimes. Last time\n> > > > > he used \"git stash pop\", he got into a merge conflict. After he\n> > > > > resolved the conflict, he did not know what to do to get the\n> > > > > repository into the wanted state. In his case, it was only \"git\n> > > > > add <resolved files>\" followed by a \"git reset\" and a \"git stash\n> > > > > drop\", but there may be more involved cases when your index is\n> > > > > not clean before \"git stash pop\" and you want to have your index\n> > > > > as before.\n> > > > >\n> > > > > This led to the idea to have something like \"git stash\n> > > > > --continue\"[1]\n> > > >\n> > > > More like \"git stash pop --continue\". Without the \"pop\" command,\n> > > > it does not make too much sense.\n> > >\n> > > Why not?  git should be able to remember what stash command created\n> > > the conflict.  Why should I have to?  Maybe the fire alarm goes off\n> > > right when I run the stash command, and by the time I get back to it\n> > > I can't remember which operation I did.  It would be nice to be able\n> > > to tell git to \"just finish off (or abort) the stash operation,\n> > > whatever it was\".\n> >\n> > That reeks of a big potential for confusion.\n> >\n> > Imagine for example a total Git noob who calls `git stash list`,\n> > scrolls two pages down, then hits `q` by mistake. How would you\n> > explain to that user that `git stash --continue` does not continue\n> > showing the list at the third page?\n> \n> Sorry, but I have trouble taking that example seriously.  It assumes\n> such a level of \"noobness\" that the user doesn't even understand how\n> standard command output paging works, not just with git but with any\n> shell command.\n\nYeah, well, I thought you understood what I meant.\n\nThe example was the best I could come up with quickly, and it only tried\nto show that there are *other* stash operations that one might perceive\nto happen at the same time as the \"pop\" operation, so your flimsical\ncomment \"why not continue the latest operation\" may very well be\nambiguous.\n\nAnd if it is not ambiguous in \"stash\", it certainly will be in other Git\noperations. And therefore, having a DWIM in \"stash\" to allow \"--continue\"\nwithout any specific subcommand, but not having it in other Git commands,\nis just a very poor user interface design. It is prone to confuse users,\nwhich is always a hallmark of a bad user interface.\n\nHence my objection to \"git stash --continue\". No argument in favor of \"git\nstash --continue\" I heard so far comes even close to being convincing.\n\n> > Even worse: `git stash` (without arguments) defaults to the `save`\n> > operation, so any user who does not read the documentation (and who\n> > does?) would assume that `git stash --continue` *also* implies `save`.\n> \n> Like the first example, your user is trying to \"continue\" a command that\n> is already complete.\n\nSays who? You may understand the semantics better than other users, but\nwho are you to judge?\n\nBut that's besides the point.\n\nMy point (which you did not quite understand) was that it can be ambiguous\nwhat to continue when looking at *all* Git commands. To special-case \"git\nstash\"'s user interface makes things more confusing, and therefore less\nusable for everyone.\n\nAnd even with `git stash apply`, you could construct a very plausible\nscenario (which does not work yet, but we may want to make it work): if\n`git stash apply` causes conflicts, and `git stash apply stash@{1}`\nconflicts in a *different* set of files, why don't we allow the second\noperation to succeed (adding its conflicts)?\n\nThat example is like `git cherry-pick -n` with two different commits, both\nof which conflict with the current worktree, but in different files. Both\ncherry-picks would do their job if called after one another, and the\nresult is a worktree with the *combined* conflicts. That is a legitimate\nuse case (which I happened to *actually* perform just the other day).\n\nIf we fix \"git stash\" (and there is no reason we should not), it would\nalso allow \"git stash pop; git stash pop\" to work with two stashes that\nboth conflict with the current worktree, just in different files.\n\nSo I challenge you to get less hung up on the *exact* example I present,\nand to try to see through the example what the issue is that I am trying\nto get at.\n\n> > If that was not enough, there would still be the overall design of\n> > Git's user interface. You can call it confusing, inconsistent, with a\n> > lot of room for improvement, and you would be correct. But none of\n> > Git's commands has a `--continue` option that remembers the latest\n> > subcommand and continues that. To introduce that behavior in `git\n> > stash` would disimprove the situation.\n> \n> I think it's more the case that none of the current continuable commands\n> have subcommands (though I can't think of all the continuable or\n> abortable operations offhand, so maybe I'm wrong).  I think we're\n> discussing new UI ground here.\n\nNope, we are not entering new UI ground here. The principle is clear with\nthe existing --continue options: you pass them to the same operation that\nyou want to continue. By that reasoning, \"git stash --continue\" should\ncontinue the (implicit) \"save\" operation. But that is not at all what you\nwant.\n\n> And since the pattern is already \"git foo --continue\",\n\nBut foo *is the operation*! By that reasoning, you should agree that \"git\nstash --continue\" is *wrong*!\n\n> Think of it this way:  All the currently continuable/abortable commands\n> put the repository in a shaky state, where performing certain other\n> operations would be ill advised.  Attempting to start a rebase while a\n> merge conflict is unresolved, for example.  IIRC, git actually tries to\n> stop users from shooting their feet in this way.\n> \n> And so it should be for the stash operation:  If applying a stash yields\n> a conflict, it has to be resolved or aborted before something like a\n> rebase or merge is attempted.\n\nThat already happens, and I have no idea how you think this safe-guarding\nhas anything to do whether the \"--continue\" option makes sense in \"git\nstash\", or only in \"git stash pop\".\n\n> In the long run, I think there's even the possibility of generic \"git\n> continue\" and \"git abort\" commands,\n\nWrong.\n\nYou can call \"git cherry-pick\" (and \"git cherry-pick --continue\") while\nrunning a \"git rebase -i\".\n\nYou can run \"git rebase\", \"git stash\", \"git cherry-pick\" and many other\ncommands while running a \"git bisect\".\n\nYou can even run a \"git rebase\" or a \"git cherry-pick\" while resolving an\ninterrupted \"git am\".\n\nMany, many examples that make it *impossible* for Git to know *what* you\nwant to continue, *what* you want to abort.\n\n> > At least `git stash pop --continue` would be consistent with all other\n> > `--continue` options in Git that I can think of...\n> \n> Alas, I disagree!\n\nSure, you are free to disagree.\n\nAnd syntactially, you are even correct: \"git <something> <something-else>\n--continue\" is inconsistent with \"git <something> --continue\".\n\nBut semantically, i.e. when you look at the *meaning* of those\n\"<something>\"s, you are incorrect: the \"--continue\" option always goes\nwith the *operation* that needs to be continued. Always, always, always.\nIf you continue a rebase, it is \"git rebase --continue\", *not* \"git\n--continue\". If you continue a revert, it is \"git revert --continue\". And\nso it should be for popping a stash: \"git stash pop --continue\". Because\nthe operation is specified by \"git stash pop\", not by \"git stash\". There\nis really not much you can argue sanely about that.\n\nCiao,\nJohannes\n"},{"id":"309731","messageId":"alpine.DEB.2.20.1701191650470.3469@virtualbox","threadId":"44888","inReplyTo":"e273c7c8-278a-061c-44fd-4808b53d0475@gmx.net","subject":"Re: [RFC] stash --continue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-19T15:54:36Z","receivedAt":"2017-01-19T15:54:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stephan,\n\nOn Wed, 18 Jan 2017, Stephan Beyer wrote:\n\n> PPS: Any opinions about the mentioned \"backwards-compatibility\" issue\n> that people are then forced to finish their commits with \"--continue\"\n> instead of \"git reset\" or \"git commit\"?\n\nMaybe you could make it so that \"git reset\" and \"git commit\" would still\nwork as before, and reset the state so that \"git stash pop --continue\"\ncould complain that there is nothing to continue?\n\nSimilar to how we remove CHERRY_PICK_HEAD during a `git reset --hard`,\nmaybe?\n\nCiao,\nJohannes\n"},{"id":"309750","messageId":"aa8104ad-45f4-7bef-f199-6e6021cf0c06@xiplink.com","threadId":"44888","inReplyTo":"alpine.DEB.2.20.1701191341530.3469@virtualbox","subject":"Re: [RFC] stash --continue","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2017-01-19T18:38:04Z","receivedAt":"2017-01-19T18:38:57Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 2017-01-19 10:49 AM, Johannes Schindelin wrote:\n> Hi Marc,\n>\n> On Wed, 18 Jan 2017, Marc Branchaud wrote:\n>\n>> On 2017-01-18 11:34 AM, Johannes Schindelin wrote:\n>>>\n>>> On Wed, 18 Jan 2017, Marc Branchaud wrote:\n>>>\n>>>> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n>>>>\n>>>>> On Mon, 16 Jan 2017, Stephan Beyer wrote:\n>>>>>\n>>>>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time\n>>>>>> he used \"git stash pop\", he got into a merge conflict. After he\n>>>>>> resolved the conflict, he did not know what to do to get the\n>>>>>> repository into the wanted state. In his case, it was only \"git\n>>>>>> add <resolved files>\" followed by a \"git reset\" and a \"git stash\n>>>>>> drop\", but there may be more involved cases when your index is\n>>>>>> not clean before \"git stash pop\" and you want to have your index\n>>>>>> as before.\n>>>>>>\n>>>>>> This led to the idea to have something like \"git stash\n>>>>>> --continue\"[1]\n>>>>>\n>>>>> More like \"git stash pop --continue\". Without the \"pop\" command,\n>>>>> it does not make too much sense.\n>>>>\n>>>> Why not?  git should be able to remember what stash command created\n>>>> the conflict.  Why should I have to?  Maybe the fire alarm goes off\n>>>> right when I run the stash command, and by the time I get back to it\n>>>> I can't remember which operation I did.  It would be nice to be able\n>>>> to tell git to \"just finish off (or abort) the stash operation,\n>>>> whatever it was\".\n>>>\n>>> That reeks of a big potential for confusion.\n>>>\n>>> Imagine for example a total Git noob who calls `git stash list`,\n>>> scrolls two pages down, then hits `q` by mistake. How would you\n>>> explain to that user that `git stash --continue` does not continue\n>>> showing the list at the third page?\n>>\n>> Sorry, but I have trouble taking that example seriously.  It assumes\n>> such a level of \"noobness\" that the user doesn't even understand how\n>> standard command output paging works, not just with git but with any\n>> shell command.\n>\n> Yeah, well, I thought you understood what I meant.\n>\n> The example was the best I could come up with quickly, and it only tried\n> to show that there are *other* stash operations that one might perceive\n> to happen at the same time as the \"pop\" operation, so your flimsical\n> comment \"why not continue the latest operation\" may very well be\n> ambiguous.\n>\n> And if it is not ambiguous in \"stash\", it certainly will be in other Git\n> operations. And therefore, having a DWIM in \"stash\" to allow \"--continue\"\n> without any specific subcommand, but not having it in other Git commands,\n> is just a very poor user interface design. It is prone to confuse users,\n> which is always a hallmark of a bad user interface.\n\nPlease don't underestimate the power of syntactic consistency in helping \nusers achieve their goals.  Having some commands use \"git foo \n--continue\" while others use \"git foo bar --continue\" *will* confuse \npeople, regardless of how logical the reasons for those differences.\n\nBut in the case of stash, I still don't see the utility in having \noperation-specific continuation.  Consider the following sequence (as \nyou say, this doesn't work yet, but making it work seems reasonable):\n\n\tgit stash pop  # creates some conflicts\n\tgit stash apply stash@{4} # creates some other conflicts\n\t# (User resolves the conflicts created by the pop.)\n\tgit stash pop --continue\n\nGiven the description of the original proposal (do \"git reset; git stash \ndrop\"), what's the state of the index and the working tree?\n\nIn particular, what has the user gained by continuing just that pop?\n\nAnother thing to ask is, how common is such a scenario likely to be?  I \nsuggest that it will be far more common for users to resolve all the \nconflicts and then want to continue all their interrupted stash \noperations.  If so, fussily forcing them to explicitly continue the pop \nand the apply is just a waste.\n\n> Hence my objection to \"git stash --continue\". No argument in favor of \"git\n> stash --continue\" I heard so far comes even close to being convincing.\n\nWell, what about the potential for a slippery slope?  If the user is \nforced to be specific about continuing either a pop or an apply, why \nwouldn't git allow them to be specific about *which* pop or apply they \nwant to continue?  Consider another hypothetical scenario:\n\n\tgit stash pop  # creates some conflicts\n\tgit stash pop  # creates some more conflicts\n\tgit stash pop  # creates even more conflicts\n\t# (User resolves the conflicts created by second pop.)\n\tgit stash pop --continue\n\t# Oops, there's still some unresovled pops!\n\nObviously the user isn't ready to finish off all the pops, so they'll \nwant some way to specify which pop to continue.  Dealing with that just \nfeels like a lot of work for minimal benefit.\n\n>>> Even worse: `git stash` (without arguments) defaults to the `save`\n>>> operation, so any user who does not read the documentation (and who\n>>> does?) would assume that `git stash --continue` *also* implies `save`.\n>>\n>> Like the first example, your user is trying to \"continue\" a command that\n>> is already complete.\n>\n> Says who? You may understand the semantics better than other users, but\n> who are you to judge?\n>\n> But that's besides the point.\n>\n> My point (which you did not quite understand) was that it can be ambiguous\n> what to continue when looking at *all* Git commands. To special-case \"git\n> stash\"'s user interface makes things more confusing, and therefore less\n> usable for everyone.\n>\n> And even with `git stash apply`, you could construct a very plausible\n> scenario (which does not work yet, but we may want to make it work): if\n> `git stash apply` causes conflicts, and `git stash apply stash@{1}`\n> conflicts in a *different* set of files, why don't we allow the second\n> operation to succeed (adding its conflicts)?\n\nRunning those two commands should be perfectly fine.  The interesting \nquestion is what it means to *continue* from that state.\n\n> That example is like `git cherry-pick -n` with two different commits, both\n> of which conflict with the current worktree, but in different files. Both\n> cherry-picks would do their job if called after one another, and the\n> result is a worktree with the *combined* conflicts. That is a legitimate\n> use case (which I happened to *actually* perform just the other day).\n\nI don't mean to suggest that you shouldn't be able to do that.\n\n> If we fix \"git stash\" (and there is no reason we should not), it would\n> also allow \"git stash pop; git stash pop\" to work with two stashes that\n> both conflict with the current worktree, just in different files.\n\nSounds fine to me.  So, what would it mean to continue from that state?\n\n> So I challenge you to get less hung up on the *exact* example I present,\n> and to try to see through the example what the issue is that I am trying\n> to get at.\n>\n>>> If that was not enough, there would still be the overall design of\n>>> Git's user interface. You can call it confusing, inconsistent, with a\n>>> lot of room for improvement, and you would be correct. But none of\n>>> Git's commands has a `--continue` option that remembers the latest\n>>> subcommand and continues that. To introduce that behavior in `git\n>>> stash` would disimprove the situation.\n>>\n>> I think it's more the case that none of the current continuable commands\n>> have subcommands (though I can't think of all the continuable or\n>> abortable operations offhand, so maybe I'm wrong).  I think we're\n>> discussing new UI ground here.\n>\n> Nope, we are not entering new UI ground here. The principle is clear with\n> the existing --continue options: you pass them to the same operation that\n> you want to continue. By that reasoning, \"git stash --continue\" should\n> continue the (implicit) \"save\" operation. But that is not at all what you\n> want.\n>\n>> And since the pattern is already \"git foo --continue\",\n>\n> But foo *is the operation*! By that reasoning, you should agree that \"git\n> stash --continue\" is *wrong*!\n\nNo, in the user's mind *stash* is the operation!  The user is doing \n\"stash\" stuff.  She doesn't care if the conflicts came from a pop or an \napply.  She has resolved the conflicts, and now she just wants to continue.\n\nThere's no confusion about possibly continuing some other stash \nsubcommand, like save or list or drop.  None of those other commands are \ncontinuable.  In the following sequence\n\n\tgit stash \"let me save my work now\"\n\tgit stash --continue\n\nThat continue command does nothing, regardless of whether the implied \nsave command succeeded or failed.  There's simply nothing to continue.\n\nWith the sequence\n\n\tgit stash pop  # creates some conflicts\n\tgit stash \"got some popped conflicts\"\n\tgit stash --continue\n\nAgain the continue command should do nothing:  If the save command \nsucceeded it should have cleaned up the interrupted pop.  If the save \ncommand failed, then the continue command can't continue from a \nconflicted state.  (OTOH, a \"git stash --abort\" would abort the pop.)\n\n>> Think of it this way:  All the currently continuable/abortable commands\n>> put the repository in a shaky state, where performing certain other\n>> operations would be ill advised.  Attempting to start a rebase while a\n>> merge conflict is unresolved, for example.  IIRC, git actually tries to\n>> stop users from shooting their feet in this way.\n>>\n>> And so it should be for the stash operation:  If applying a stash yields\n>> a conflict, it has to be resolved or aborted before something like a\n>> rebase or merge is attempted.\n>\n> That already happens, and I have no idea how you think this safe-guarding\n> has anything to do whether the \"--continue\" option makes sense in \"git\n> stash\", or only in \"git stash pop\".\n>\n>> In the long run, I think there's even the possibility of generic \"git\n>> continue\" and \"git abort\" commands,\n>\n> Wrong.\n>\n> You can call \"git cherry-pick\" (and \"git cherry-pick --continue\") while\n> running a \"git rebase -i\".\n>\n> You can run \"git rebase\", \"git stash\", \"git cherry-pick\" and many other\n> commands while running a \"git bisect\".\n>\n> You can even run a \"git rebase\" or a \"git cherry-pick\" while resolving an\n> interrupted \"git am\".\n>\n> Many, many examples that make it *impossible* for Git to know *what* you\n> want to continue, *what* you want to abort.\n\nRight, I'd missed that.  I agree that a generic \"git continue\" is nonsense.\n\n\t\tM.\n\n"},{"id":"309788","messageId":"alpine.DEB.2.20.1701192220320.3469@virtualbox","threadId":"44888","inReplyTo":"aa8104ad-45f4-7bef-f199-6e6021cf0c06@xiplink.com","subject":"Re: [RFC] stash --continue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-19T21:30:44Z","receivedAt":"2017-01-19T21:31:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Marc,\n\nOn Thu, 19 Jan 2017, Marc Branchaud wrote:\n\n> On 2017-01-19 10:49 AM, Johannes Schindelin wrote:\n> >\n> > On Wed, 18 Jan 2017, Marc Branchaud wrote:\n> >\n> > > On 2017-01-18 11:34 AM, Johannes Schindelin wrote:\n> > > >\n> > > > On Wed, 18 Jan 2017, Marc Branchaud wrote:\n> > > >\n> > > > > On 2017-01-16 05:54 AM, Johannes Schindelin wrote:\n> > > > >\n> > > > > > On Mon, 16 Jan 2017, Stephan Beyer wrote:\n> > > > > >\n> > > > > > > a git-newbie-ish co-worker uses git-stash sometimes. Last\n> > > > > > > time he used \"git stash pop\", he got into a merge conflict.\n> > > > > > > After he resolved the conflict, he did not know what to do\n> > > > > > > to get the repository into the wanted state. In his case, it\n> > > > > > > was only \"git add <resolved files>\" followed by a \"git\n> > > > > > > reset\" and a \"git stash drop\", but there may be more\n> > > > > > > involved cases when your index is not clean before \"git\n> > > > > > > stash pop\" and you want to have your index as before.\n> > > > > > >\n> > > > > > > This led to the idea to have something like \"git stash\n> > > > > > > --continue\"[1]\n> > > > > >\n> > > > > > More like \"git stash pop --continue\". Without the \"pop\"\n> > > > > > command, it does not make too much sense.\n> > > > >\n> > > > > Why not?  git should be able to remember what stash command\n> > > > > created the conflict.  Why should I have to?  Maybe the fire\n> > > > > alarm goes off right when I run the stash command, and by the\n> > > > > time I get back to it I can't remember which operation I did.\n> > > > > It would be nice to be able to tell git to \"just finish off (or\n> > > > > abort) the stash operation, whatever it was\".\n> > > >\n> > > > That reeks of a big potential for confusion.\n> > > >\n> > > > Imagine for example a total Git noob who calls `git stash list`,\n> > > > scrolls two pages down, then hits `q` by mistake. How would you\n> > > > explain to that user that `git stash --continue` does not continue\n> > > > showing the list at the third page?\n> > >\n> > > Sorry, but I have trouble taking that example seriously.  It assumes\n> > > such a level of \"noobness\" that the user doesn't even understand how\n> > > standard command output paging works, not just with git but with any\n> > > shell command.\n> >\n> > Yeah, well, I thought you understood what I meant.\n> >\n> > The example was the best I could come up with quickly, and it only\n> > tried to show that there are *other* stash operations that one might\n> > perceive to happen at the same time as the \"pop\" operation, so your\n> > flimsical comment \"why not continue the latest operation\" may very\n> > well be ambiguous.\n> >\n> > And if it is not ambiguous in \"stash\", it certainly will be in other\n> > Git operations. And therefore, having a DWIM in \"stash\" to allow\n> > \"--continue\" without any specific subcommand, but not having it in\n> > other Git commands, is just a very poor user interface design. It is\n> > prone to confuse users, which is always a hallmark of a bad user\n> > interface.\n> \n> Please don't underestimate the power of syntactic consistency in helping\n> users achieve their goals.  Having some commands use \"git foo\n> --continue\" while others use \"git foo bar --continue\" *will* confuse\n> people, regardless of how logical the reasons for those differences.\n\nBut that ship has already sailed!\n\nBy your reasoning, it was a mistake to introduce subcommands such as `git\nstash pop` in the first place.\n\n> But in the case of stash, I still don't see the utility in having\n> operation-specific continuation.\n\nStephan already gave one good example where you want it: if `git stash\npop` fails, you may want to continue by *not* dropping the stash via `git\nstash apply --continue`.\n\n> Consider the following sequence (as you say, this doesn't work yet, but\n> making it work seems reasonable):\n> \n> \tgit stash pop  # creates some conflicts\n> \tgit stash apply stash@{4} # creates some other conflicts\n> \t# (User resolves the conflicts created by the pop.)\n> \tgit stash pop --continue\n\nYes, that would make sense: the `pop` would actually drop the stash entry.\n\n> Given the description of the original proposal (do \"git reset; git stash\n> drop\"), what's the state of the index and the working tree?\n> \n> In particular, what has the user gained by continuing just that pop?\n\nThat it was completed.\n\n> Another thing to ask is, how common is such a scenario likely to be?\n\nWe have millions of users. Even a 0.001% chance of anything happening will\nbite users, who will then come back to bite us.\n\nLet's just not go into the \"how likely is this\" game.\n\n> I suggest that it will be far more common for users to resolve all the\n> conflicts and then want to continue all their interrupted stash\n> operations.  If so, fussily forcing them to explicitly continue the pop\n> and the apply is just a waste.\n\nNo, it is not a waste, as we require the user nothing else than to be\nprecise. Do you want to continue the \"stash pop\"? Okay, then, call \"git\nstash pop --continue\".\n\n> [... a lot of stuff skipped, as it is basically ignoring my point...]\n>\n> > But foo *is the operation*! By that reasoning, you should agree that\n> > \"git stash --continue\" is *wrong*!\n> \n> No, in the user's mind *stash* is the operation!\n\nHow can that be true? In the user's mind, the *stash* operation is\nequivalent to the *stash save* operation! Because that is what happens\nwhen you call \"git stash\" without any further command-line parameters.\n\nAt this point I will stop commenting on this issue, as I have said all\nthat I wanted to say about it, at least once. If I failed to get my points\nacross so far, I simply won't be understood.\n\nCiao,\nJohannes\n"},{"id":"309835","messageId":"1fba12e3-78f0-6b2f-31ca-8d888744b9aa@xiplink.com","threadId":"44888","inReplyTo":"alpine.DEB.2.20.1701192220320.3469@virtualbox","subject":"Re: [RFC] stash --continue","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2017-01-20T15:19:42Z","receivedAt":"2017-01-20T15:19:47Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 2017-01-19 04:30 PM, Johannes Schindelin wrote:\n>\n> At this point I will stop commenting on this issue, as I have said all\n> that I wanted to say about it, at least once. If I failed to get my points\n> across so far, I simply won't be understood.\n\nYes, we're obviously looking at this from completely different perspectives.\n\nStephan (or whoever) if you decide to do this work, I will be content \nwith whichever way you choose to go.\n\n\t\tM.\n\n"},{"id":"309837","messageId":"alpine.DEB.2.20.1701201625440.3469@virtualbox","threadId":"44888","inReplyTo":"1fba12e3-78f0-6b2f-31ca-8d888744b9aa@xiplink.com","subject":"Re: [RFC] stash --continue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-20T15:27:00Z","receivedAt":"2017-01-20T15:33:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Marc,\n\nOn Fri, 20 Jan 2017, Marc Branchaud wrote:\n\n> On 2017-01-19 04:30 PM, Johannes Schindelin wrote:\n> >\n> > At this point I will stop commenting on this issue, as I have said all\n> > that I wanted to say about it, at least once. If I failed to get my\n> > points across so far, I simply won't be understood.\n> \n> Yes, we're obviously looking at this from completely different\n> perspectives.\n\nYes, but you claim to argue from the users' perspective, while I actually\nwork with enough users to be really certain that I described their mental\nmodel of what an operation is very accurately.\n\n> Stephan (or whoever) if you decide to do this work, I will be content\n> with whichever way you choose to go.\n\nSo you only wanted to argue and not actually do anything? Tsk, tsk...\n\n:-)\n\nCiao,\nJohannes\n"}]}