From: Andy Whitcroft <apw@shadowen.org>
To: Janos Farkas <chexum+dev@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git PATH reordering
Date: Mon, 06 Nov 2006 13:58:39 +0000 [thread overview]
Message-ID: <454F3F8F.2080808@shadowen.org> (raw)
In-Reply-To: <priv$efbe06146839$619d340665@200611.gmail.com>
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..
prev parent reply other threads:[~2006-11-06 13:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-06 13:33 git PATH reordering Janos Farkas
2006-11-06 13:58 ` Andy Whitcroft [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=454F3F8F.2080808@shadowen.org \
--to=apw@shadowen.org \
--cc=chexum+dev@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).