From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mon, 15 Sep 2008 20:22:19 GMT
Subject: Re: [PATCH] help git-upload-pack find git
Message-ID: <48CEC3FB.5070101@drmicha.warpmail.net>
In-Reply-To: <7vzlm9b3v4.fsf@gitster.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 15.09.2008 21:34:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> The corresponding bug was reported by Paul Johnston who wondered why
>> "git clone" failed when specifying --upload-pack for an out-of-$PATH
>> installation of git.  I'm not sure whether we should encourage this, but
>> the --upload-pack option clearly gives the impression that
>> git-upload-pack is all that is needed.
> 
> Another possibility would be to teach exec_cmd.c:setup_path() to add the
> directory specified by $(bindir) to PATH after we add GIT_EXEC_PATH to
> it.  That should cover the case David Miller reported, shouldn't it?

Probably. I read that thread only after submitting my patch for
upload-pack but suspected that other server side incarnations may suffer
from the same problem.

I was actually surprised that setup_path() uses argv0_path without
setting it, same as with argv_exec_path. I assumed this is for a good
reason, I'm lacking the code base overview to judge this myself.

In any case, git.c sets argv0_path early, messes a bit with argv[0] and
calls setup_path afterwards anyways. So adding the path in setup_path()
should not hurt any "git foo" command.

One could construe situations where even that wouldn't help, because
git-upload-pack can't pass --exec-dir to git and they can be in
different locations - but I think that's crazy.

git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.
setup_path() needs to get a parameter. If shell.c should profit from the
change then it needs to be taught how to pass an absolute path to
do_{generic,cvs}_cmd().

So, I guess the general approach (change setup() path and have every
caller profit) is OK. OK with you?

Michael