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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 1, 2017, 23:29 UTC
Message-ID: <xmqqtvzitpjv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171001201604.GA30301@hank>

Thomas Gummerer <t.gummerer@gmail.com> writes:

Show 9 quoted lines

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