{"thread":{"id":"33019","subject":"Better handling of erroneous git stash save \"somemessage\" --keep-index","startedAt":"2013-02-26T15:59:47Z","lastAt":"2013-02-26T17:00:46Z","messageCount":5,"participants":["Gunnlaugur Thor Briem","Junio C Hamano","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210327","messageId":"CAPs+M8JvcnTcZiySmpMBuOxek4THRnTx0jkZv7NHaSDNLhcOAQ@mail.gmail.com","threadId":"33019","inReplyTo":null,"subject":"Better handling of erroneous git stash save \"somemessage\" --keep-index","fromName":"Gunnlaugur Thor Briem","fromEmail":"gunnlaugur@gmail.com","sentAt":"2013-02-26T15:59:47Z","receivedAt":"2013-02-26T15:59:47Z","isPatch":false,"sender":{"key":"gunnlaugur@gmail.com","avatar":"https://avatars.githubusercontent.com/u/153580?v=4"},"body":"Hi,\n\nthe command:\n\ngit stash save \"some message\" --keep-index\n\nstashes everything, including the index, and adds the \"--keep-index\"\nto the message. The manual labor of separating index hunks from hunks\nto stash is lost. This is in version 1.8.1.3.\n\nThis is a user error, of course (per the man page, parameters are not\naccepted after the message). But it would be better handled by\nerroring out, with a message like \"git stash save does not permit\nparameters after the stash message\".\n\nCheers,\n\nGulli\n"},{"id":"210329","messageId":"7vwqtvm4yr.fsf@alter.siamese.dyndns.org","threadId":"33019","inReplyTo":"CAPs+M8JvcnTcZiySmpMBuOxek4THRnTx0jkZv7NHaSDNLhcOAQ@mail.gmail.com","subject":"Re: Better handling of erroneous git stash save \"somemessage\" --keep-index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-26T16:10:04Z","receivedAt":"2013-02-26T16:10:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gunnlaugur Thor Briem writes:\n\n> the command:\n>\n> git stash save \"some message\" --keep-index\n>\n> stashes everything, including the index, and adds the \"--keep-index\"\n> to the message. The manual labor of separating index hunks from hunks\n> to stash is lost. This is in version 1.8.1.3.\n>\n> This is a user error, of course (per the man page, parameters are not\n> accepted after the message). But it would be better handled by\n> erroring out, with a message like \"git stash save does not permit\n> parameters after the stash message\".\n\nThen the user cannot say\n\n\tgit stash save some message that consists of multiple words\n\nno? You may have a WIP to enhance the behaviour of one option and\nyou might want to say\n\n\tgit stash save wip: tweak behaviour of --keep-index\n\nto save it away when switching to higher priority task.\n"},{"id":"210331","messageId":"vpq1uc3cagy.fsf@grenoble-inp.fr","threadId":"33019","inReplyTo":"7vwqtvm4yr.fsf@alter.siamese.dyndns.org","subject":"Re: Better handling of erroneous git stash save \"somemessage\" --keep-index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-26T16:21:17Z","receivedAt":"2013-02-26T16:21:17Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Gunnlaugur Thor Briem writes:\n>\n>> the command:\n>>\n>> git stash save \"some message\" --keep-index\n>>\n>> stashes everything, including the index, and adds the \"--keep-index\"\n>> to the message. The manual labor of separating index hunks from hunks\n>> to stash is lost. This is in version 1.8.1.3.\n\nNot lost, it's saved as part of the stash. \"git stash pop --index\" will\nrestore it.\n\n>> This is a user error, of course (per the man page, parameters are not\n>> accepted after the message). But it would be better handled by\n>> erroring out, with a message like \"git stash save does not permit\n>> parameters after the stash message\".\n>\n> Then the user cannot say\n>\n> \tgit stash save some message that consists of multiple words\n>\n> no?\n\nI didn't even know that multi-words messages would be allowed this way.\nThat seems to me to be really weird indeed.\n\nI can't say\n\n git commit -m multi word message\n\nso why would people want to omit quotes for \"git stash\" is a total\nmystery. That said, we can't deny it right now, to preserve backward\ncompatibility.\n\nMy feeling is that \"git stash save\" should learn a \"-m, --message\"\noption analogous to the one of \"git commit\", and then the \"message on\nthe command-line\" syntax could be deprecated.\n\n(One nice side effect would be that in the very long term, we may want\nto allow \"git stash save -- \" to do a limited stash)\n\nBut maybe it's not worth the effort, I don't know.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210333","messageId":"CAPs+M8+5yXz59PiOKwFpkUZkOoR-LA+jt0CWEAPz9Eq9VnaAcQ@mail.gmail.com","threadId":"33019","inReplyTo":"7vwqtvm4yr.fsf@alter.siamese.dyndns.org","subject":"Re: Better handling of erroneous git stash save \"somemessage\" --keep-index","fromName":"Gunnlaugur Thor Briem","fromEmail":"gunnlaugur@gmail.com","sentAt":"2013-02-26T16:46:49Z","receivedAt":"2013-02-26T16:46:49Z","isPatch":false,"sender":{"key":"gunnlaugur@gmail.com","avatar":"https://avatars.githubusercontent.com/u/153580?v=4"},"body":"On Tue, Feb 26, 2013 at 4:10 PM, Junio C Hamano wrote:\n> Then the user cannot say\n>\n> git stash save some message that consists of multiple words\n>\n> no? You may have a WIP to enhance the behaviour of one option and\n> you might want to say\n>\n> git stash save wip: tweak behaviour of --keep-index\n>\n> to save it away when switching to higher priority task.\n\nIn this case (which must be rarer than --keep-index intended as a\nparameter) the user gets the error message, the problem is pretty\nclear, and the workaround is very easy, quote the message:\n\n git stash save \"wip: tweak behaviour of --keep-index\"\n\n... which also is more conventional on the command line.\n\nTo minimize the behavior change, it could apply solely for the case of\nknown parameters to this command (like --keep-index), so that:\n\n git stash save wip: tweak behaviour of --froob-nob\n\nwould still work like before. That's less consistent, but then again,\nthis is just a matter of catching very likely errors to avoid lost\nwork.\n\nExpressing a multi-word message without quotes on the command line is\nunconventional (in general, though maybe not in the use of git-stash)\nso it seems reasonable to let that usage be the one that gets\ninconvenienced.\n\n-Gulli\n\n(Sorry about the initial reply to you alone Junio)\n"},{"id":"210337","messageId":"7vsj4jm2m9.fsf@alter.siamese.dyndns.org","threadId":"33019","inReplyTo":"vpq1uc3cagy.fsf@grenoble-inp.fr","subject":"Re: Better handling of erroneous git stash save \"somemessage\" --keep-index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-26T17:00:46Z","receivedAt":"2013-02-26T17:00:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> I didn't even know that multi-words messages would be allowed this way.\n> That seems to me to be really weird indeed.\n\nYeah, but it is understandable why it was done that way, considering\ntaht the whole point of \"stash\" is to save away quickly for higher\npriority interrupt. IIRC, earlier iterations of the command did not\neven require you to say \"save\", i.e.\n\n\tgit stash wip: futzing with --keep-index\n\nwould have been a perfectly good invocation.\n\n> My feeling is that \"git stash save\" should learn a \"-m, --message\"\n> option analogous to the one of \"git commit\", and then the \"message on\n> the command-line\" syntax could be deprecated.\n>\n> (One nice side effect would be that in the very long term, we may want\n> to allow \"git stash save -- \" to do a limited stash)\n>\n> But maybe it's not worth the effort, I don't know.\n\nYeah, if the user wants to be more elaborate perhaps\n\n\tgit checkout -b temp\n git commit -m 'whatever message' -a\n\tgit checkout -\n\nwould suffice; \"stash\" is for smaller changes in a very tentative\nnature that do not deserve such a long command sequence, so\nrequiring \"-m\" may make the command less useful.\n"}]}