Re: git grep: search whole tree by default?

[Jeff King <peff@peff.net>]

On Wed, Oct 23, 2013 at 10:43:36PM +0200, Matthieu Moy wrote:

> That may be an option. In the case of "git add -u", it was a bit more
> complicated, since a badly used "git add" somehow looses data (not very
> serious, you may only loos the index). So, saying after the fact "oh, by
> the way, I messed up the index" was not a very good transition plan.
> 
> In the case of "grep", I'm starting to get convinced that it's OK to do
> so, because the user can basically re-run grep with the right argument
> if needed.

For the same reason, is it insane to want a config option to switch the
default when no command-line option is given? These days I am mostly
working on reasonably-sized projects, and would generally prefer
full-tree grep. But in a past life, I worked on some large projects
where I would never touch anything outside of a particular subtree, and
I generally wanted a more limited grep (i.e., I would park my cwd in
/repo/subsystem1 rather than /repo and work from there, and hits in
/repo/subsystem2 were just useless noise).

That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will already have to use "." or ":/" to
be explicit (if they care) since the behavior is changing.

> The warning could be de-activable with an advice.* option.

Such a config option could also be used to shut up the warning. Though
if the behavior change is deemed non-intrusive enough to not merit a
deprecation period, I am not really sure it is worth having a noisy
warning.

-Peff