Thread (1 message) 1 message, 1 author, 2017-10-05

Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

From: Junio C Hamano <hidden>
Date: 2017-10-05 05:17:03

"Robert P. J. Day" [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help