Ed Avis <ed.avis@xxxxxxxx> 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?
