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. -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