Re: git grep: search whole tree by default?

From: Jeff King <peff@peff.net>
Date: Oct 24, 2013, 02:27 UTC
Message-ID: <20131024022736.GA24992@sigill.intra.peff.net>
In-Reply-To: <vpqy55jogzr.fsf@anie.imag.fr>

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

Show 8 quoted lines

> 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