Re: [PATCH] grep: --full-tree

Junio C Hamano wrote:
 > Jeff King <peff@peff.net> 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.