{"thread":{"id":"46859","subject":"\"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","startedAt":"2017-09-29T16:26:33Z","lastAt":"2017-10-05T05:17:03Z","messageCount":6,"participants":["Robert P. J. Day","Thomas Gummerer","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"329181","messageId":"alpine.LFD.2.21.1709290650530.1446@localhost.localdomain","threadId":"46859","inReplyTo":null,"subject":"\"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-09-29T16:26:26Z","receivedAt":"2017-09-29T16:26:33Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n  from the man page:\n\n\"If the --include-untracked option is used, all untracked files are\nalso stashed and then cleaned up with git clean, leaving the working\ndirectory in a very clean state. If the --all option is used instead\n                                                             ^^^^^^^\nthen the ignored files are stashed and cleaned in addition to the\nuntracked files.\"\n\n  the use of the word \"instead\" suggests you can use one of those\noptions, or the other, but not both at the same time. but it seems you\ncan combine them, so that paragraph seems a bit misleading, no?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n\n"},{"id":"329316","messageId":"20171001201604.GA30301@hank","threadId":"46859","inReplyTo":"alpine.LFD.2.21.1709290650530.1446@localhost.localdomain","subject":"Re: \"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2017-10-01T20:16:04Z","receivedAt":"2017-10-01T20:15:21Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 09/29, Robert P. J. Day wrote:\n> \n>   from the man page:\n> \n> \"If the --include-untracked option is used, all untracked files are\n> also stashed and then cleaned up with git clean, leaving the working\n> directory in a very clean state. If the --all option is used instead\n>                                                              ^^^^^^^\n> then the ignored files are stashed and cleaned in addition to the\n> untracked files.\"\n> \n>   the use of the word \"instead\" suggests you can use one of those\n> options, or the other, but not both at the same time. but it seems you\n> can combine them, so that paragraph seems a bit misleading, no?\n\nLooking at the code, really only one (the last one that's specified on\nthe command line) is respected, so I think the man page is correct.\nThis happens silently, where I guess your impression that it's\npossible to combine them comes from.\n\nThis is fine when --include-untracked is specified first, as --all\nimplies --include-untracked, but I guess the behaviour could be a bit\nsurprising if --all is specified first and --include-untracked later\non the command line.\n\nChanging this could possibly break someone that just adds parameters\nto their 'git stash' invocation, but I'm tempted to say allowing both\nat once is a bug, and change it to make git die when both are\nspecified.  Do you have any inserest in submitting a patch that fixes\nthis? :)\n\n> rday\n> \n> -- \n> \n> ========================================================================\n> Robert P. J. Day                                 Ottawa, Ontario, CANADA\n>                         http://crashcourse.ca\n> \n> Twitter:                                       http://twitter.com/rpjday\n> LinkedIn:                               http://ca.linkedin.com/in/rpjday\n> ========================================================================\n> \n"},{"id":"329318","messageId":"alpine.LFD.2.21.1710011643070.27165@localhost.localdomain","threadId":"46859","inReplyTo":"20171001201604.GA30301@hank","subject":"Re: \"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-10-01T20:44:01Z","receivedAt":"2017-10-01T20:44:09Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sun, 1 Oct 2017, Thomas Gummerer wrote:\n\n> On 09/29, Robert P. J. Day wrote:\n> >\n> >   from the man page:\n> >\n> > \"If the --include-untracked option is used, all untracked files\n> > are also stashed and then cleaned up with git clean, leaving the\n> > working directory in a very clean state. If the --all option is\n> > used instead\n> >\n> > ^^^^^^^ then the ignored files are stashed and cleaned in addition\n> > to the untracked files.\"\n> >\n> >   the use of the word \"instead\" suggests you can use one of those\n> > options, or the other, but not both at the same time. but it seems\n> > you can combine them, so that paragraph seems a bit misleading,\n> > no?\n>\n> Looking at the code, really only one (the last one that's specified\n> on the command line) is respected, so I think the man page is\n> correct. This happens silently, where I guess your impression that\n> it's possible to combine them comes from.\n>\n> This is fine when --include-untracked is specified first, as --all\n> implies --include-untracked, but I guess the behaviour could be a\n> bit surprising if --all is specified first and --include-untracked\n> later on the command line.\n>\n> Changing this could possibly break someone that just adds parameters\n> to their 'git stash' invocation, but I'm tempted to say allowing\n> both at once is a bug, and change it to make git die when both are\n> specified.  Do you have any inserest in submitting a patch that\n> fixes this? :)\n\n  sure, might as well jump in with both feet. is there another example\nin the code of mutually exclusive options so i can just steal the\nerror code?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"329348","messageId":"xmqqtvzitpjv.fsf@gitster.mtv.corp.google.com","threadId":"46859","inReplyTo":"20171001201604.GA30301@hank","subject":"Re: \"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-10-01T23:29:40Z","receivedAt":"2017-10-01T23:29:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Gummerer <t.gummerer@gmail.com> writes:\n\n> This is fine when --include-untracked is specified first, as --all\n> implies --include-untracked, but I guess the behaviour could be a bit\n> surprising if --all is specified first and --include-untracked later\n> on the command line.\n>\n> Changing this could possibly break someone that just adds parameters\n> to their 'git stash' invocation, but I'm tempted to say allowing both\n> at once is a bug, and change it to make git die when both are\n> specified.\n\nI am on the fence.\n\nIf this were --include=untracked vs --include=all, then I'd say your\nsuggestion will violate the usual expectation of \"on the command\nline, last one wins\", but \"--include-untracked\" and \"--all\" are\nspelled very differently, and may not look all that related to a\ncasual reader, so the expectation for \"the last one wins\" might be\nweaker than usual.\n\nBut once we start complaining to a command line that has both,\nsaying they are mutually exclusive, people will realize that they\nare very much closely related options, even though spelled quite\ndifferently.  And at that point, they will find it very unreasonable\nthat we do not follow the usual \"the last one wins\" rule but error\nout X-<.\n\nIf I really cared deeply about these two options [*1*], I would\nthink that the ideal longer term direction would be to introduce\n--include={untracked,all-crufts} to replace and deprecate the\ncurrent two options.  And then we make sure --include=* forms follow\nthe usual \"last one wins\" rule.\n\n\n[Footnote]\n\n*1* I personally don't, but that does not mean I will block efforts\n    by others who do to make this part of the system better.\n"},{"id":"329697","messageId":"alpine.LFD.2.21.1710041300350.9804@localhost.localdomain","threadId":"46859","inReplyTo":"xmqqtvzitpjv.fsf@gitster.mtv.corp.google.com","subject":"Re: \"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-10-04T17:05:54Z","receivedAt":"2017-10-04T17:06:01Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Mon, 2 Oct 2017, Junio C Hamano wrote:\n\n> Thomas Gummerer <t.gummerer@gmail.com> writes:\n>\n> > This is fine when --include-untracked is specified first, as --all\n> > implies --include-untracked, but I guess the behaviour could be a\n> > bit surprising if --all is specified first and --include-untracked\n> > later on the command line.\n> >\n> > Changing this could possibly break someone that just adds\n> > parameters to their 'git stash' invocation, but I'm tempted to say\n> > allowing both at once is a bug, and change it to make git die when\n> > both are specified.\n>\n> I am on the fence.\n>\n> If this were --include=untracked vs --include=all, then I'd say your\n> suggestion will violate the usual expectation of \"on the command\n> line, last one wins\", but \"--include-untracked\" and \"--all\" are\n> spelled very differently, and may not look all that related to a\n> casual reader, so the expectation for \"the last one wins\" might be\n> weaker than usual.\n>\n> But once we start complaining to a command line that has both,\n> saying they are mutually exclusive, people will realize that they\n> are very much closely related options, even though spelled quite\n> differently.  And at that point, they will find it very unreasonable\n> that we do not follow the usual \"the last one wins\" rule but error\n> out X-<.\n>\n> If I really cared deeply about these two options [*1*], I would\n> think that the ideal longer term direction would be to introduce\n> --include={untracked,all-crufts} to replace and deprecate the\n> current two options.  And then we make sure --include=* forms follow\n> the usual \"last one wins\" rule.\n>\n>\n> [Footnote]\n>\n> *1* I personally don't, but that does not mean I will block efforts\n>     by others who do to make this part of the system better.\n\n  since i'm the one who tripped over this pedantic nitpickery, i'm\nwilling to take a shot at patching it, as long as there's consensus\nfrom those *way* higher up the food chain as to what that patch should\nlook like.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n\n"},{"id":"329722","messageId":"xmqqh8ve8989.fsf@gitster.mtv.corp.google.com","threadId":"46859","inReplyTo":"alpine.LFD.2.21.1710041300350.9804@localhost.localdomain","subject":"Re: \"man git-stash\" explanation of \"--include-untracked\" and \"--all\" seems ambiguous","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-10-05T05:16:54Z","receivedAt":"2017-10-05T05:17:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n\n>> If this were --include=untracked vs --include=all, then I'd say your\n>> suggestion will violate the usual expectation of \"on the command\n>> line, last one wins\", but \"--include-untracked\" and \"--all\" are\n>> spelled very differently, and may not look all that related to a\n>> casual reader, so the expectation for \"the last one wins\" might be\n>> weaker than usual.\n>>\n>> But once we start complaining to a command line that has both,\n>> saying they are mutually exclusive, people will realize that they\n>> are very much closely related options, even though spelled quite\n>> differently.  And at that point, they will find it very unreasonable\n>> that we do not follow the usual \"the last one wins\" rule but error\n>> out X-<.\n>>\n>> If I really cared deeply about these two options [*1*], I would\n>> think that the ideal longer term direction would be to introduce\n>> --include={untracked,all-crufts} to replace and deprecate the\n>> current two options.  And then we make sure --include=* forms follow\n>> the usual \"last one wins\" rule.\n>>\n>>\n>> [Footnote]\n>>\n>> *1* I personally don't, but that does not mean I will block efforts\n>>     by others who do to make this part of the system better.\n>\n>   since i'm the one who tripped over this pedantic nitpickery, i'm\n> willing to take a shot at patching it, as long as there's consensus\n> from those *way* higher up the food chain as to what that patch should\n> look like.\n\nThat is rather hard to arrange.  I can give you, with some effort,\nhow a series of patches I may produce would look like if I were\ninterested in this topic.  But I cannot guarantee you that it would\nbecome the consensus solution among other contributors on the list.\n\nAnd more importantly, designing a good UI/UX (both the final user\ninterface, and the minimization of inconvenience to users during the\ntransition period) is more than 80% of the work required for a topic\nlike this, and by the time I outline something which may or may not\nbe close to a consensus solution, more than half of the effort\nneeded has already spent by _me_, on the topic that _I_ am not all\nthat interested.  That does not sound like a great economy to me.\n\nI can still help polish a concrete proposal with the usual review on\ndesign and implementation, of course.\n"}]}