* "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).