On Wed, 16 Jul 2008, Chris Cowan wrote:
quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html