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

From: Jeff King <peff@peff.net>
Date: Dec 2, 2015, 17:51 UTC
Message-ID: <20151202175144.GA18550@sigill.intra.peff.net>
In-Reply-To: <xmqqd1uo69vf.fsf@gitster.mtv.corp.google.com>

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

Show 18 quoted lines

> 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