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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux