Janos Farkas wrote:
> 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.
>
> 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?
>
> 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..
-apw
-
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