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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html