Re: [RFC PATCH 3/3] grep: add support for grepping in submodules

From: Jens Lehmann <jens.lehmann@web.de>
Date: Sep 30, 2010, 11:24 UTC
Message-ID: <4CA4738A.9040503@web.de>
In-Reply-To: <4CA3C569.4020309@gmail.com>

Am 30.09.2010 01:02, schrieb Chris Packham:

> I actually started with --recursive and switched to
> --recurse-submodules. One thing with this is the standard grep
> --recursive option which may cause some confusion if people expect git
> grep to behave like normal grep.

Guess how I came to use "--recurse-submodules" for recursive checkout in the first place ;-) But the fact that clone already uses it weighs stronger here I suppose ...

Show 6 quoted lines

> One more thought on this that has been hanging around in my mind. I
> sometimes want to do something on all but one submodule, in this case
> with grep I'm fairly likely to want to skip a linux repository because I
> already know the thing I'm looking for is in userland. Maybe in the
> future we can make --recursive take an argument that allows us to
> specify/restrict which submodules get included in the command invocation.

Hmm, maybe adding an option to "git grep" to exclude a pathspec would make more sense?

>> It seems you want to use strbuf_detach() here so that this argv[]
>> stays valid after the strbuf_release() at the end of this function.

> I'll look into strbuf_detatch. The tricky thing will be keeping track of
> what to free at the end of grep_submodule.

Right, but if you push the strbuf operations into one of the calling functions you can achieve that more easily.

> Yeah this is the part I was struggling with a little. It would be easy
> to save argv before any option processing but I wondered if that would
> be frowned upon as an overhead for non-submodule usages.

Yup, but as you are only copying a pointer array the overhead is very small. And if the code gets much easier that way (as I would expect) that price is well paid.