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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2020, 18:40 UTC
Message-ID: <xmqq369x38c6.fsf@gitster.c.googlers.com>
In-Reply-To: <MN2PR11MB3663C042590097D7A7F4B2409DF10@MN2PR11MB3663.namprd11.prod.outlook.com>

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

Show 7 quoted lines

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