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

Jeff King [off-list ref] writes:

On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:

quoted

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

Certainly I think that would be an improvement. But again, it suffers
from the "you must remember to do this" as above. I really want "git
grep" to Do What I Mean.

And /this-is-absolute is one way to tell "grep" What You Mean.  I do not
claim it would be the _best_ way (I just concocted it up a few minutes ago
without giving it deep thought).  Do you have a better alternative in
mind?

I have to wonder: is "git grep" really plumbing or porcelain? It is
really just a wrapper for

  git ls-files | xargs grep

Do people actually use it in their scripts? Should they be?

The issue is not necessarily "scripts", but "what people use the output
for".

My earlier "push is excusable" was primarily because "push" tends to be
the _final_ action in the chain of events, as opposed to "ls-files" and
"grep" output that are meant to be used by the user to _decide_ what to
do next depending on what they find, and as such, the latter has more
problem if they changed behaviour based on the configuration.


[Footnote]

*1* It won't be only get_pathspec(), but we would also need to teach
verify_filename() and verify_non_filename() about the new convention.