Feature request: 'git grep' over multiple working trees

Feature request: 'git grep' over multiple working trees

[Ed Avis]

If the current directory contains several git working trees (each in its own subdirectory) then 'git grep' should search all of them.  It would be roughly equivalent to

% for i in * ; do (cd $i ; git grep whatever); done

except that the filenames listed would have the full path.

As you see it's fairly simple to script up, and there are tools to do it (one called 'multi'), but having it built in to 'git grep' would be handy.
If the current directory doesn't contain any git working trees, then 'git grep' can die as it does now.  If there are some working trees and some random other stuff, it can warn and skip the other stuff.

Please ignore confidentiality stuff after this point.

Re: Feature request: 'git grep' over multiple working trees

[Junio C Hamano]

Ed Avis <ed.avis@qmaw.com> writes:

> If the current directory contains several git working trees (each
> in its own subdirectory) then 'git grep' should search all of
> them.  It would be roughly equivalent to
>
> % for i in * ; do (cd $i ; git grep whatever); done
>
> except that the filenames listed would have the full path.

I am not sure where that "should search" comes from.

In my $HOME/w directory, I have working trees of various
repositories, belonging to different and unrelated projects.
Should "git grep foo" in there search in everywhre?

Are you looking for "grep -r --exclude=.git" (not a git command at
all)?

In other words, surely anybody can wish anything nonsensical, but I
do not quite see the point for adding such a mode to "Git".

It sounds like saying 'git grep' "should" search all of them if the
current directly is a git repository with several git commits, which
would be roughly equivalent to

    git rev-list --all |
    while read rev
    do
	git grep -e pattern... $rev
    done

Similarly, you could say that 'git grep' "should" search all of them
if the current directory is a git repository with several branches,
which would be roughly equivalent to

    git for-each-ref --format='%(objectname)' refs/heads/ |
    while read rev
    do
	git grep -e pattern... $rev
    done

Neither of the above smell like a reasonable use of "should", at
least to me, and yours does not, either.

What is the real use case, if any, of what you are proposing?

RE: Feature request: 'git grep' over multiple working trees

[Ed Avis]

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.