From: Andreas Ericsson <ae@op5.se>
Date: Wed, 11 Jan 2006 00:06:42 GMT
Subject: Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
Message-ID: <43C44C12.3050609@op5.se>
In-Reply-To: <1136924980.11717.603.camel@brick.watson.ibm.com>

Michal Ostrowski wrote:
> On Tue, 2006-01-10 at 11:47 -0800, Junio C Hamano wrote:
> 
>>
>>>Good point. Perhaps we should only prepend to path when the directory
>>>isn't already in $PATH, or append rather than prepend.
>>
>>I think appending not prepending would stop letting me say
>>
>> $ GIT_EXEC_PATH=/usr/libexec/git-core/0.99.9k git foo
>>
>>to try out older version, if I have more recent git in my PATH.
>>But I agree with Michal it is not nice to affect invocations of
>>"diff" (and things spawned from hooks, which would inherit PATH
>>from receive-pack).
>>

So how about prepending only when the directory isn't already in the 
PATH? That can be done with a two-line patch to git.c only.

It will break the "diff in another dir" scenario in the highly unlikely 
event that the other diff is located in the same dir as the git suite, 
isn't supposed to be used, and the directory in question isn't in $PATH 
already. People who have such a setup will be too ashamed to admit it, 
so we're not likely to be blamed for it either. ;)

>>
> 
> 
> How about searching for executables in the following places, and in this
> order:
> 
> 1. --exec-path setting, if any
> 2. GIT_EXEC_PATH env var, if set
> 3. PATH (never modified)
> 4. Value of ${bindir} at build time
> 

This is more or less what's done today, with the exception that $PATH 
isn't searched and it throws an error immediately no matter where 
exec_path (the git.c variable) came from.

Adding $PATH to the search-pattern would be a simple matter of falling 
back to execvp() if execve(), but then we could end up with running 
programs from a different release while the user thinks he/she's 
specifically running 1.0.3... Tricky problem, really.

> 
> Secondly, the shell scripts as is cannot utilize this search order as
> long as they don't religiously use the git potty internally.  If we were
> to "sed -e 's/git-/git /g' -i git*.sh" (grotesquely simplified of
> course) then they would. 
> 

I think this has been done, but as it happened to be convenient. I'd 
prefer if the git potty could keep prepending the GIT_EXEC_PATH to the 
path, really. We're bound to run into setup-related problems otherwise, 
such as;

Alice writes a script that works fine for her and her friends, so she 
shares it freely with Bob and whoever else might be listening. Bob's 
git-tools aren't in the $PATH but he keeps the potty handy at all times. 
He can't always run it through the potty because in some code-paths 
Alice's script uses git-tools without going through the potty. Bob 
thinks Alice puts entropy in her programs on purpose, so Alice flees, 
sobbing and shaking in anger and betrayed trust. The two never speak again.

Luckily, Bruce Schneier shows up and saves the day.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231