git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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..


      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).