git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Janos Farkas <chexum+dev@gmail.com>
To: git@vger.kernel.org
Subject: git PATH reordering
Date: Mon, 6 Nov 2006 14:33:04 +0100	[thread overview]
Message-ID: <priv$efbe06146839$619d340665@200611.gmail.com> (raw)

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?

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.

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:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-06 13:33 Janos Farkas [this message]
2006-11-06 13:58 ` git PATH reordering Andy Whitcroft

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='priv$efbe06146839$619d340665@200611.gmail.com' \
    --to=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).