* "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous
@ 2017-09-29 16:26 Robert P. J. Day
2017-10-01 20:16 ` Thomas Gummerer
0 siblings, 1 reply; 6+ messages in thread
From: Robert P. J. Day @ 2017-09-29 16:26 UTC (permalink / raw)
To: Git Mailing list
from the man page:
"If the --include-untracked option is used, all untracked files are
also stashed and then cleaned up with git clean, leaving the working
directory in a very clean state. If the --all option is used instead
^^^^^^^
then the ignored files are stashed and cleaned in addition to the
untracked files."
the use of the word "instead" suggests you can use one of those
options, or the other, but not both at the same time. but it seems you
can combine them, so that paragraph seems a bit misleading, no?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous 2017-09-29 16:26 "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous Robert P. J. Day @ 2017-10-01 20:16 ` Thomas Gummerer 2017-10-01 20:44 ` Robert P. J. Day 2017-10-01 23:29 ` Junio C Hamano 0 siblings, 2 replies; 6+ messages in thread From: Thomas Gummerer @ 2017-10-01 20:16 UTC (permalink / raw) To: Robert P. J. Day; +Cc: Git Mailing list On 09/29, Robert P. J. Day wrote: > > from the man page: > > "If the --include-untracked option is used, all untracked files are > also stashed and then cleaned up with git clean, leaving the working > directory in a very clean state. If the --all option is used instead > ^^^^^^^ > then the ignored files are stashed and cleaned in addition to the > untracked files." > > the use of the word "instead" suggests you can use one of those > options, or the other, but not both at the same time. but it seems you > can combine them, so that paragraph seems a bit misleading, no? Looking at the code, really only one (the last one that's specified on the command line) is respected, so I think the man page is correct. This happens silently, where I guess your impression that it's possible to combine them comes from. This is fine when --include-untracked is specified first, as --all implies --include-untracked, but I guess the behaviour could be a bit surprising if --all is specified first and --include-untracked later on the command line. Changing this could possibly break someone that just adds parameters to their 'git stash' invocation, but I'm tempted to say allowing both at once is a bug, and change it to make git die when both are specified. Do you have any inserest in submitting a patch that fixes this? :) > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous 2017-10-01 20:16 ` Thomas Gummerer @ 2017-10-01 20:44 ` Robert P. J. Day 2017-10-01 23:29 ` Junio C Hamano 1 sibling, 0 replies; 6+ messages in thread From: Robert P. J. Day @ 2017-10-01 20:44 UTC (permalink / raw) To: Thomas Gummerer; +Cc: Git Mailing list On Sun, 1 Oct 2017, Thomas Gummerer wrote: > On 09/29, Robert P. J. Day wrote: > > > > from the man page: > > > > "If the --include-untracked option is used, all untracked files > > are also stashed and then cleaned up with git clean, leaving the > > working directory in a very clean state. If the --all option is > > used instead > > > > ^^^^^^^ then the ignored files are stashed and cleaned in addition > > to the untracked files." > > > > the use of the word "instead" suggests you can use one of those > > options, or the other, but not both at the same time. but it seems > > you can combine them, so that paragraph seems a bit misleading, > > no? > > Looking at the code, really only one (the last one that's specified > on the command line) is respected, so I think the man page is > correct. This happens silently, where I guess your impression that > it's possible to combine them comes from. > > This is fine when --include-untracked is specified first, as --all > implies --include-untracked, but I guess the behaviour could be a > bit surprising if --all is specified first and --include-untracked > later on the command line. > > Changing this could possibly break someone that just adds parameters > to their 'git stash' invocation, but I'm tempted to say allowing > both at once is a bug, and change it to make git die when both are > specified. Do you have any inserest in submitting a patch that > fixes this? :) sure, might as well jump in with both feet. is there another example in the code of mutually exclusive options so i can just steal the error code? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous 2017-10-01 20:16 ` Thomas Gummerer 2017-10-01 20:44 ` Robert P. J. Day @ 2017-10-01 23:29 ` Junio C Hamano 2017-10-04 17:05 ` Robert P. J. Day 1 sibling, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2017-10-01 23:29 UTC (permalink / raw) To: Thomas Gummerer; +Cc: Robert P. J. Day, Git Mailing list Thomas Gummerer <t.gummerer@gmail.com> writes: > This is fine when --include-untracked is specified first, as --all > implies --include-untracked, but I guess the behaviour could be a bit > surprising if --all is specified first and --include-untracked later > on the command line. > > Changing this could possibly break someone that just adds parameters > to their 'git stash' invocation, but I'm tempted to say allowing both > at once is a bug, and change it to make git die when both are > specified. I am on the fence. If this were --include=untracked vs --include=all, then I'd say your suggestion will violate the usual expectation of "on the command line, last one wins", but "--include-untracked" and "--all" are spelled very differently, and may not look all that related to a casual reader, so the expectation for "the last one wins" might be weaker than usual. But once we start complaining to a command line that has both, saying they are mutually exclusive, people will realize that they are very much closely related options, even though spelled quite differently. And at that point, they will find it very unreasonable that we do not follow the usual "the last one wins" rule but error out X-<. If I really cared deeply about these two options [*1*], I would think that the ideal longer term direction would be to introduce --include={untracked,all-crufts} to replace and deprecate the current two options. And then we make sure --include=* forms follow the usual "last one wins" rule. [Footnote] *1* I personally don't, but that does not mean I will block efforts by others who do to make this part of the system better. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous 2017-10-01 23:29 ` Junio C Hamano @ 2017-10-04 17:05 ` Robert P. J. Day 2017-10-05 5:16 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Robert P. J. Day @ 2017-10-04 17:05 UTC (permalink / raw) To: Junio C Hamano; +Cc: Thomas Gummerer, Git Mailing list On Mon, 2 Oct 2017, Junio C Hamano wrote: > Thomas Gummerer <t.gummerer@gmail.com> writes: > > > This is fine when --include-untracked is specified first, as --all > > implies --include-untracked, but I guess the behaviour could be a > > bit surprising if --all is specified first and --include-untracked > > later on the command line. > > > > Changing this could possibly break someone that just adds > > parameters to their 'git stash' invocation, but I'm tempted to say > > allowing both at once is a bug, and change it to make git die when > > both are specified. > > I am on the fence. > > If this were --include=untracked vs --include=all, then I'd say your > suggestion will violate the usual expectation of "on the command > line, last one wins", but "--include-untracked" and "--all" are > spelled very differently, and may not look all that related to a > casual reader, so the expectation for "the last one wins" might be > weaker than usual. > > But once we start complaining to a command line that has both, > saying they are mutually exclusive, people will realize that they > are very much closely related options, even though spelled quite > differently. And at that point, they will find it very unreasonable > that we do not follow the usual "the last one wins" rule but error > out X-<. > > If I really cared deeply about these two options [*1*], I would > think that the ideal longer term direction would be to introduce > --include={untracked,all-crufts} to replace and deprecate the > current two options. And then we make sure --include=* forms follow > the usual "last one wins" rule. > > > [Footnote] > > *1* I personally don't, but that does not mean I will block efforts > by others who do to make this part of the system better. since i'm the one who tripped over this pedantic nitpickery, i'm willing to take a shot at patching it, as long as there's consensus from those *way* higher up the food chain as to what that patch should look like. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous 2017-10-04 17:05 ` Robert P. J. Day @ 2017-10-05 5:16 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2017-10-05 5:16 UTC (permalink / raw) To: Robert P. J. Day; +Cc: Thomas Gummerer, Git Mailing list "Robert P. J. Day" <rpjday@crashcourse.ca> writes: >> If this were --include=untracked vs --include=all, then I'd say your >> suggestion will violate the usual expectation of "on the command >> line, last one wins", but "--include-untracked" and "--all" are >> spelled very differently, and may not look all that related to a >> casual reader, so the expectation for "the last one wins" might be >> weaker than usual. >> >> But once we start complaining to a command line that has both, >> saying they are mutually exclusive, people will realize that they >> are very much closely related options, even though spelled quite >> differently. And at that point, they will find it very unreasonable >> that we do not follow the usual "the last one wins" rule but error >> out X-<. >> >> If I really cared deeply about these two options [*1*], I would >> think that the ideal longer term direction would be to introduce >> --include={untracked,all-crufts} to replace and deprecate the >> current two options. And then we make sure --include=* forms follow >> the usual "last one wins" rule. >> >> >> [Footnote] >> >> *1* I personally don't, but that does not mean I will block efforts >> by others who do to make this part of the system better. > > since i'm the one who tripped over this pedantic nitpickery, i'm > willing to take a shot at patching it, as long as there's consensus > from those *way* higher up the food chain as to what that patch should > look like. That is rather hard to arrange. I can give you, with some effort, how a series of patches I may produce would look like if I were interested in this topic. But I cannot guarantee you that it would become the consensus solution among other contributors on the list. And more importantly, designing a good UI/UX (both the final user interface, and the minimization of inconvenience to users during the transition period) is more than 80% of the work required for a topic like this, and by the time I outline something which may or may not be close to a consensus solution, more than half of the effort needed has already spent by _me_, on the topic that _I_ am not all that interested. That does not sound like a great economy to me. I can still help polish a concrete proposal with the usual review on design and implementation, of course. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-10-05 5:17 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-29 16:26 "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous Robert P. J. Day 2017-10-01 20:16 ` Thomas Gummerer 2017-10-01 20:44 ` Robert P. J. Day 2017-10-01 23:29 ` Junio C Hamano 2017-10-04 17:05 ` Robert P. J. Day 2017-10-05 5:16 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).