On Thu, Oct 24, 2013 at 12:40 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: > >> 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. > > There is a big difference between "scripted use will have an escape > hatch" and "scripted use will not be inconvenienced". We *know* > scripts will be inconvenienced with or without such a configuration > variable, as they *have* to be updated if they rely on the current > behaviour of "git grep" that limits its search to the current > directory when fed no pathspec (and if their users want to keep the > current behaviour of such scripts). Anything short of a warning (or > even erroring out) that is designed to annoy the users during the > transition period will help ease the pain of transition of scripts. > > An annoying warning still can only *ease*, but cannot eliminate, the > pain of transition. The scripts need to be updated to adjust to the > new behaviour; there is no getting around to it. > > Even if we ignore the "helping your colleague at her terminal", cf. > > http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133683 > > issue for now, adding a new configuration variable from day one > makes the transition of scripts somewhat worse, I am afraid. Doing > so robs us a way to add such an annoying warning to help people > foresee problems in their existing scripts before the default > changes (the configuration presumably will disable the "this command > line will behave differently after the default changes" warning). > > As I said, I think we can train people without an annoying warning, > as hits outside their current directory will serve as an annoyance > already, and people who set such a configuration in their repository > (or $HOME/.gitconfig), get used to the chosen behaviour too much, > and get surprised when they get to use a vanilla intallation of Git > (either helping colleague or setting up a new work environment) have > only themselves to blame, so it may not be too big a deal. > > But I do not think the same reasoning extends to scripted uses X-<. The set of people that script "git grep" may in fact be pretty low / almost non-existent so it may be a non-issue, but here's my one data point: For git-cola, this change in behavior would not make any difference. It already jumps to the top-level during startup so its grep feature is unaffected. It'd be good to hear from other script writers but that's my $.02. -- David -- 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