On Wed, Nov 25, 2009 at 2:49 PM, Jeff King <peff@xxxxxxxx> wrote: > I'm not sure I really understand. "git grep" is routinely producing > wrong results for me _now_. I'd like to configure it so that it produces > results more sensible to me. If I am the one who sets the configuration > variable to something more sensible for my workflow, who am I hurting? Config options are not free - they add code bloat, increase the maintenance and testing burden, make it harder to explain how Git works if you have to say things like "if config X is true, then Git does ..., otherwise Git does ..., unless config Y is false, in which case Git does ...", make it harder to debug when Git doesn't do what you expected if you have to check a bunch of configs to figure out what the behavior should be, and make it harder to develop new features since you have to consider how they might interact with lots of config options. So I think the bar for adding config options, especially ones that fundamentally change user visible behavior, should be set pretty high, and this one doesn't even come close to getting over the bar. I like Junio's suggestion to make paths starting with / anchored to the top. If that were added then it would be easy for users to tell Git what they want; they just have to use the right pathspec, which I think is a very reasonable requirement. That's my 2 cents.... James -- 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