Re: git PATH reordering

From: Andy Whitcroft <apw@shadowen.org>
Date: Nov 6, 2006, 13:58 UTC
Message-ID: <454F3F8F.2080808@shadowen.org>
In-Reply-To: <priv$efbe06146839$619d340665@200611.gmail.com>

Janos Farkas wrote:

Show 26 quoted lines

> Hi!
> 
> I'm facing an issue which seems to originate about a year ago, so I'm a
> bit late :)
> 
> Apparently, most git commands seem to tweak their PATH to make sure the
> corresponding version of a subcommand gets ran in the case there are
> multiple ones in there.
> 
> The thing is, since this "ensuring" is done by prepend_to_path(), which
> can then change all exec() afterwards.   Usually, that's not a problem,
> but that made git run an unexpectedly different ssh command for remote
> access.  When I discovered what the problem is, I easily fixed it by
> setting GIT_SSH to the explicit path, and I can live with that, but it's
> a bit confusing.
> 
> I don't want to start a neverending thread, so if my bikeshed doesn't
> interest you, I'll give up :)  But the way it's done now seems to be for
> the case which should be very rare.
> 
> As I see, all this PATH manipulation logic was meant to solve the case
> when the desired "git" version is not in the path or some mismatching
> components of it is.  Including the case when you want to point some
> higher level tool to one specific version of "git" to be used,
> irrespective of PATH.  Is this the right way to do it?  Is it
> really required at all?

Well its pretty important if you run /usr/local/foo/git clone its running git-clone from the version you think it is going to.

Show 10 quoted lines

> 
> Apart from getting rid of this (possibly useful?) munging, I could see
> about two ways to change the behavior to less surprising:
> 
> - Don't make PATH munging if "our" path is in the PATH already.
> - Save the PATH before munging, and restore before any non-git command
>   is run.  This is a bit complex, as multiple languages are used,
>   including sh..
> 
> Both could make sense, but I don't think either is the correct way.

It sounds a lot like we want to be running the equivalent of `dirname $0`/git-cmd over git-cmd in all cases to ensure we get the right ones. Perhaps we could export that as GIT_BIN inside the tools.

Something like this might work for shell:

	export GIT_BIN=${GIT_BIN:-`dirname $0`}

	$GIT_BIN/git-rev-list ...

Thoughts?

Show 9 quoted lines

> 
> What bit me, if someone cares about the details, is that on my system,
> everything is in the correct path, even git*.  There is however a private
> ~/bin at the front of the PATH containing some preferred/fixed versions
> of some system tools.  When git (living as a normal citizen in /usr/bin)
> does its PATH munging, it puts /usr/bin in the front of the path,
> skipping this well built house of cards.  As I said, I can live with
> that, since only ssh is one that I can designate as "important", and
> that one can be set separately with GIT_SSH, but still..