Junio C Hamano venit, vidit, dixit 15.09.2008 21:34:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
