Michael J Gruber schrieb:
> 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.
It argv_exec_path comes from git --exec-path=..., hence, git (via git.c)
is the only caller of setup_path() that is able to set it. We can leave
that one out of the equation.
> 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?
Have you studied the commit message of e1464ca7bb0d (Record the command
invocation path early) and the context in which this commit occurs? It's
about relocatable git installations and how system_path() derives various
other paths from argv[0].
Please show how you think you could change setup_path(), but keep in mind
that in git.c you neither can do the equivalent of git_set_argv0_path()
later nor setup_path() earlier.
-- Hannes
--
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
