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

From: Jeff King <peff@peff.net>
Date: Nov 25, 2009, 21:49 UTC
Message-ID: <20091125214949.GA31473@coredump.intra.peff.net>
In-Reply-To: <7vmy2as319.fsf@alter.siamese.dyndns.org>

On Wed, Nov 25, 2009 at 01:33:22PM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> 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

I do like that idea (and I cannot see any obvious flaw in it, though I have only been think for a few minutes). I am not sure how useful it will be for other commands. Conceptually I might use it for "diff" and "status" (the new version that uses pathspecs sanely :) ), but those commands generally aren't a big deal. I haven't touched anything in the uninteresting subtree, so there is nothing to report.

Hmm. Actually, after having considered that, don't we actually allow absolute paths in diff to do out-of-tree diffs? I haven't looked at how that code interacts with get_pathspec.

Show 8 quoted lines

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

Well, what I meant is that I shouldn't have to tell it each time what I mean. I should be able to set up configuration so that it does what I want (well, ideally, it would just read my mind, but I am willing to concede that point). That is, I don't want to have to remember "git grep --full-tree" or "git grep /" every time, because I am not likely to notice when I forget. I want to set up "when I am in this directory, this is probably what I want".

Show 5 quoted lines

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

I'm not sure I really understand. "git grep" is routinely producing wrong results for me _now_. I'd like to configure it so that it produces results more sensible to me. If I am the one who sets the configuration variable to something more sensible for my workflow, who am I hurting?

-Peff