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