{"thread":{"id":"43229","subject":"git PATH reordering","startedAt":"2006-11-06T13:33:04Z","lastAt":"2006-11-06T13:58:39Z","messageCount":2,"participants":["Janos Farkas","Andy Whitcroft"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294081","messageId":"priv$efbe06146839$619d340665@200611.gmail.com","threadId":"43229","inReplyTo":null,"subject":"git PATH reordering","fromName":"Janos Farkas","fromEmail":"chexum+dev@gmail.com","sentAt":"2006-11-06T13:33:04Z","receivedAt":"2006-11-06T13:33:04Z","isPatch":false,"sender":{"key":"chexum+dev@gmail.com","avatar":null},"body":"Hi!\n\nI'm facing an issue which seems to originate about a year ago, so I'm a\nbit late :)\n\nApparently, most git commands seem to tweak their PATH to make sure the\ncorresponding version of a subcommand gets ran in the case there are\nmultiple ones in there.\n\nThe thing is, since this \"ensuring\" is done by prepend_to_path(), which\ncan then change all exec() afterwards.   Usually, that's not a problem,\nbut that made git run an unexpectedly different ssh command for remote\naccess.  When I discovered what the problem is, I easily fixed it by\nsetting GIT_SSH to the explicit path, and I can live with that, but it's\na bit confusing.\n\nI don't want to start a neverending thread, so if my bikeshed doesn't\ninterest you, I'll give up :)  But the way it's done now seems to be for\nthe case which should be very rare.\n\nAs I see, all this PATH manipulation logic was meant to solve the case\nwhen the desired \"git\" version is not in the path or some mismatching\ncomponents of it is.  Including the case when you want to point some\nhigher level tool to one specific version of \"git\" to be used,\nirrespective of PATH.  Is this the right way to do it?  Is it\nreally required at all?\n\nApart from getting rid of this (possibly useful?) munging, I could see\nabout two ways to change the behavior to less surprising:\n\n- Don't make PATH munging if \"our\" path is in the PATH already.\n- Save the PATH before munging, and restore before any non-git command\n  is run.  This is a bit complex, as multiple languages are used,\n  including sh..\n\nBoth could make sense, but I don't think either is the correct way.\n\nWhat bit me, if someone cares about the details, is that on my system,\neverything is in the correct path, even git*.  There is however a private\n~/bin at the front of the PATH containing some preferred/fixed versions\nof some system tools.  When git (living as a normal citizen in /usr/bin)\ndoes its PATH munging, it puts /usr/bin in the front of the path,\nskipping this well built house of cards.  As I said, I can live with\nthat, since only ssh is one that I can designate as \"important\", and\nthat one can be set separately with GIT_SSH, but still..\n\n"},{"id":"294485","messageId":"454F3F8F.2080808@shadowen.org","threadId":"43229","inReplyTo":"priv$efbe06146839$619d340665@200611.gmail.com","subject":"Re: git PATH reordering","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-06T13:58:39Z","receivedAt":"2006-11-06T13:58:39Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Janos Farkas wrote:\n> Hi!\n> \n> I'm facing an issue which seems to originate about a year ago, so I'm a\n> bit late :)\n> \n> Apparently, most git commands seem to tweak their PATH to make sure the\n> corresponding version of a subcommand gets ran in the case there are\n> multiple ones in there.\n> \n> The thing is, since this \"ensuring\" is done by prepend_to_path(), which\n> can then change all exec() afterwards.   Usually, that's not a problem,\n> but that made git run an unexpectedly different ssh command for remote\n> access.  When I discovered what the problem is, I easily fixed it by\n> setting GIT_SSH to the explicit path, and I can live with that, but it's\n> a bit confusing.\n> \n> I don't want to start a neverending thread, so if my bikeshed doesn't\n> interest you, I'll give up :)  But the way it's done now seems to be for\n> the case which should be very rare.\n> \n> As I see, all this PATH manipulation logic was meant to solve the case\n> when the desired \"git\" version is not in the path or some mismatching\n> components of it is.  Including the case when you want to point some\n> higher level tool to one specific version of \"git\" to be used,\n> irrespective of PATH.  Is this the right way to do it?  Is it\n> really required at all?\n\nWell its pretty important if you run /usr/local/foo/git clone its\nrunning git-clone from the version you think it is going to.\n> \n> Apart from getting rid of this (possibly useful?) munging, I could see\n> about two ways to change the behavior to less surprising:\n> \n> - Don't make PATH munging if \"our\" path is in the PATH already.\n> - Save the PATH before munging, and restore before any non-git command\n>   is run.  This is a bit complex, as multiple languages are used,\n>   including sh..\n> \n> Both could make sense, but I don't think either is the correct way.\n\nIt sounds a lot like we want to be running the equivalent of `dirname\n$0`/git-cmd over git-cmd in all cases to ensure we get the right ones.\nPerhaps we could export that as GIT_BIN inside the tools.\n\nSomething like this might work for shell:\n\n\texport GIT_BIN=${GIT_BIN:-`dirname $0`}\n\n\t$GIT_BIN/git-rev-list ...\n\nThoughts?\n\n> \n> What bit me, if someone cares about the details, is that on my system,\n> everything is in the correct path, even git*.  There is however a private\n> ~/bin at the front of the PATH containing some preferred/fixed versions\n> of some system tools.  When git (living as a normal citizen in /usr/bin)\n> does its PATH munging, it puts /usr/bin in the front of the path,\n> skipping this well built house of cards.  As I said, I can live with\n> that, since only ssh is one that I can designate as \"important\", and\n> that one can be set separately with GIT_SSH, but still..\n\n"}]}