Thanks for your reply. Please interpret 'should' in the context of this being a feature request. If you reject the request then no, it should not :-) The use case is just as you describe: having several different repositories checked out under a common root, and wanting to search all of them, while keeping the speed and other advantages of git grep. I do this multi-repos search all the time. In a pure software development context it may not make much sense. If projects are so tightly coupled that you commonly search all of them, they would be in one repository. But for in-house code in a more 'dev ops' setup it's invaluable. What code references this database table? User fred has left the company, which config files still grant him permissions? Does any other group call the Pogg() function in our in-house library? Even with a single development team you are likely to have more than one repository to search; in a larger organization you'll have other teams with their own repos which nonetheless you have to grep before you can consider changing that Pogg(). I think I'm not the only one with this use case, judging by questions on q&a sites. To me it seems like a natural (though limited) extension of the existing recursive search. It doesn't change any existing behaviour or break any scripts, since it concerns a case where the current behaviour is to give an error. I appreciate one can get bogged down in questions of what happens if the working trees are two levels deep, or there is a mixture of working trees and other stuff. I have tried to keep the scope fairly narrow by stipulating a single directory which contains git trees under its top level. I believe this is a fairly common case.
