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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 6, 2015, 03:51 UTC
Message-ID: <xmqqr3j0nsk8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20151202175144.GA18550@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> 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'd be even more wary of that, as different commands use ignore patterns for different purposes. A script may invoke "clean" and "add" and would want to use different sets of ignore patterns to emulate "precious" class (which we do not have), for example, by giving a wider ignore pattern for "add" to prevent a file that must be kept untracked outside the index while telling "clean -X" that that file is not expendable with a narrower ignore pattern. That is just one example that comes to me without thinking about the issues too hard, so I am reasonably sure that it would hurt the ecosystem to promote that the ignore pattern can be used for specifying important per-invocation input to a script.

In any case, what we've been discussing may be an interesting and potentially important tangent, but it still is a tangent while evaluating the patch in question. I do not think I'd be using the new "--exclude-from=<file>" option to "clean" (simply because I do not think I've ever used the existing "-e" option to it unless I am merely testing the command to make sure it works as advertised) myself, but I do not immediately see how it would hurt us in the future to add it now. So...