Jeff King <peff@xxxxxxxx> writes:
> .... So maybe "clean" is really the only place where people care
> about such ad-hoc exclusion. Or maybe this an opportunity to add:
>
> git --exclude='*.o' clean
>
> I dunno. I cannot think of a time when I would have used any of those
> options myself.
Me either and I do not think I ever wanted to use -e to "clean".
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.
--
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