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 -- 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