Re: [PATCH] grep: --full-tree

> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
> 
>> Jeff King <peff@peff.net> 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.