Jeff King <peff@xxxxxxxx> 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). > 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. -- 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