Re: [PATCH] clean: new option --exclude-from

[Jeff King <peff@peff.net>]

On Wed, Dec 02, 2015 at 09:25:24AM -0800, Junio C Hamano wrote:

> I do not think we should liberally add options that apply to
> anything "git" in the first place [*1*].  Limit them to ones that
> are really special and fundamental that changes the way Git
> operates, i.e. "Where is our $GIT_DIR?" is a good thing for users to
> be able to tell "git" itself.  Compared to that, the ignore patterns
> is a fringe that is used only by commands that care about the
> working tree (e.g. the global option in "git --exclude='*.o'
> ls-tree" would be meaningless).
> 
> 
> [Footnote]
> 
> *1* It would add unnecessary confusion to the end users; they have
>     to decide if they need to pass an option before or after the
>     subcommand name.  If the motivation behind the "git --option cmd"
>     is to share code and semantics for common "--option", we should
>     instead further refactor command line option handling, just like
>     the code for config handling allows us to share config_default.

My motivation isn't exactly code sharing. It is that you sometimes want
to affect sub-commands of a program, and cannot pass command line
options to them yourself.

For instance, "git-stash --include-untracked" will call "git clean"
under the hood. There is no way to say "...and treat foo.* as ignored
for this invocation". It could grow its own "-e" option, but that does
not help any other third-party scripts which call "git clean".

So IMHO this is not really about command-line options, but about the
environment in which a command is executed. Environment variables are
the obvious way to do that; "git --foo" options are just syntactic sugar
to set the variables. We could just add variables without matching
options.

I agree that we could end up proliferating such options (or environment
variables). Using the logic above, you could argue that I should be able
to affect any option of any sub-command in a script, which just gets
silly. My rule of thumb would be that if there is some implicit state in
the on-disk repo (e.g., what is in your .git/config) that you
might want to override for a one-shot invocation, then it may be a
reasonable candidate. The "git -c" config override is such an example.

In this case, it is basically adding to ".git/info/exclude", which
follows the same rule.

But like I said, I do not feel all that strongly about this particular
option. I would not use it myself. Just trying to make my reasoning
clear. :)

-Peff