On Wed, 16 Jul 2008, Chris Cowan wrote:
>
> I also saw one instance where the behavior of git-grep was affected by
> the grep selected at build time. I'm not sure if there's other
> instances within the code base, but I'm wondering whether the
> configure script can be changed to do the check for /usr/linux/bin and
> use those versions? I can imagine that similar problems may occur on
> Solaris and HPUX.
The grep selection at compile time is purely a choice between "no external
grep at all" and "whatever external grep is in $PATH".
exec_grep() literally does
..
pid = fork();
if (pid < 0)
return pid;
if (!pid) {
execvp("grep", (char **) argv);
exit(255);
}
..
so you can choose your version of external grep at run-time by just
setting PATH appropriately.
Or you can just decide that you don't want to use any external grep binary
at all, which is the compile-time choice of NO_EXTERNAL_GREP. In that
case, git will do the grep implementation all internally. It can do so,
but then it relies on the regex() library which is often less optimized
than the external grep.
Note the "often". It's possible that the external grep is never worth it,
in which case you should use NO_EXTERNAL_GREP. GNU grep happens to be very
good.
Even with an external grep configured in, you'll end up using the internal
one for the case where you ask for the index information ("--cached") or
when you ask for a particular version of the tree rather than the
checked-out tree. So regardless, you'll fall back to the internal version
for some things.
Linus
--
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
