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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2017, 05:16 UTC
Message-ID: <xmqqh8ve8989.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.LFD.2.21.1710041300350.9804@localhost.localdomain>

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

Show 30 quoted lines

>> 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.