On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > ... That is, I don't want to have to remember "git grep > > --full-tree" or "git grep /" every time > > But that cuts both ways. If you change the default to full-tree, > people will forget to put "." every time when asking to limit to the > current directory. I know. Which is why I am arguing for a configuration option. Though as a side note, I think if you are going to err, it is probably better to err in showing _too much_ data. It is easier for the user to notice the situation and re-issue the command with more limits than it is for them to notice that some results are missing and re-issue the command with fewer limits. > > If I am the one who sets the configuration variable to something more > > sensible for my workflow, who am I hurting? > > Somebody more clueful in git than you who is called to help you in your > repository when you have trouble. Obviously "you" in this sentence is not > Jeff King, but I think you get the point. Clearly, because there _isn't_ anybody more clueful than me in git. ;) But that is what my meta-rant elsewhere in the thread was about. Sure, it hurts when more clueful people are called in (and that includes asking for help on the list). But that evil to me is much less than a user who is frustrated because they have to specify the same thing to git over and over again. > And re-read what I wrote in its entirety and notice I am not disagreeing > with you that the long term goal should be to have the default changed > consistently for all command to do the full tree. The important first > step is to make sure we are capable of doing both full tree and limit to > current directory and "grep" is one example that cannot do both, and be it > the --full-tree option or new /rooted-pathspec, we need some change _now_ > that is backward compatible to pave the way for later changes. We give > people convenient way to choose between the two, and _train_ them to > express which way they want _without_ having to think. After that is > achieved, the default does not matter much and we can safely change the > default. > > Think of it as a way to force existing users _unlearn_ the command > specific default we currently have. Because any change of default will > hurt them until that is done, we should start training them as early as > possible. 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. -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