From: A Large Angry SCM Date: Wed, 25 Nov 2009 22:15:59 GMT Subject: Re: [PATCH] grep: --full-tree Message-ID: <4B0DAC9F.2010205@gmail.com> In-Reply-To: <7vmy2as319.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > Jeff King writes: > >> On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote: >> >>> So I think the posted patch alone without changing anything else would be >>> the approach to give the most benefit with the least impact to existing >>> users, at least for now. >> Yes, I meant to say in my original message but forgot to: I think >> --full-tree is an important first step, no matter what happens next. It >> gives people a way to do what they want without typing the right number >> of ".."s, and it opens up --no-full-tree if the default changes later. >> >> But I do worry about it being a command-line option. You are asking the >> user to remember to type --full-tree every time. > > We could redefine get_pathspec() to treat a pathspec that begins with a > slash to be anchored at the top, i.e. > > $ git grep -e frotz / > > would be a nicer way to spell > > $ git grep --full-tree -e frotz > > and allows you more than what you can do with --full-tree, e.g. > > $ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly > $ git grep -e frotz /linux/subtree > > If we do that, it will not be limited to "grep" but would bring uniformity > to the command set [*1*]. Of course, you can keep doing > > $ cd t > $ git grep -e frotz . > > to look inside only the current directory, and once this new convention is > accepted and widely used, it would become possible to flip the default > without causing too much pain (yes, I am agreeing with you that this is an > important first step). > > Once there is a convenient and uniform way to ask for either behaviour, no > matter what the default is, the scripts that want specific behaviour can > be updated to choose whichever they want, given enough time (say, 2.0.0). > Speaking as a `grep' user: having git-grep behave radically different than normal grep would be/is very annoying [*1*]. Speaking as a `git' user: having the different git commands use radically different path conventions, relative to other git commands, would be/is very annoying [*1*]. To make the reconciliation even more difficult, some git commands will also work on out-of-tree paths. Footnotes: [*1*] And surprising to new/occasional git users.