Jeff King wrote:
On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
I agree with all of this as far as changing the default goes. But the
point of my earlier messages was that I don't think there _is_ one sane
default. I really do want it different per-project. And that means a
configuration option.
Since grep is so useful, both interactively and scripted, outside of
git, this is a pretty convincing argument that git-grep, and all
other git commands with configurable behavior or defaults that change
over time, need a both a scripting form and an interactive form.
It is tempting to have scripts simply set a GIT_VANILLA environment
variable to ignore config options. But I think it is not quite so
simple. As a script, if I am calling "git log", do I want it to respect
the user's colorization config or not? It depends on _how_ I am calling
it. Is the output to be shown to the user, or am I going to process it
myself?
Similarly, why is the script calling "git grep"? If it is because the
script is a convenience wrapper (e.g., let's say to colorize the output
in a particular way), then it probably wants to respect my configured
choice of which files to grep. But if the script is just using "git
grep" to get data to perform some other calculation, then it probably
does care deeply about which set of files to grep.
So I think you have situations where scripts do want to invoke the
porcelain version of a command versus the plumbing. But much harder, you
have ones where they want to respect some options but not others.
<semi rhetorical>
So, what's the solution?
Have every command command take a list of configuration options to
ignore/respect?
Have every command take an option to ignore/respect _all_ configuration
options?
Have inconsistency between commands, like we have now
Have commands have all kinds of hidden/undocumented default settings?
</semi rhetorical>
--
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