On Wed, 8 Jul 2009, Junio C Hamano wrote: > Fritz Anderson <fritza@xxxxxxxxxxxx> writes: > > > On Jul 8, 2009, at 12:34 PM, Junio C Hamano wrote: > > > >> Which makes the initial "sudo git clone..." find git in _your_ path > >> before sanitization (and that is why it even starts), but then the path > >> is nuked for the git process it launches, and we cannot find > >> git-index-pack on the PATH. > >> > >> But this should be fine, as git is expected to find git-index-pack in > >> its GIT_EXEC_PATH that is compiled in the binary of "git" itself. > >> > >> Which makes me suspect that your "git" in /usr/local/bin may be > >> misconfigured. You might want to check what these tell you. > >> > >> $ git --exec-path > >> $ /usr/local/bin/git --exec-path > > > > Glad to oblige. These are the four possibilities: > > > > $ git --exec-path > > /usr/local/libexec/git-core > > $ /usr/local/bin/git --exec-path > > /usr/local/libexec/git-core > > $ sudo git --exec-path > > /usr/local/libexec/git-core > > $ sudo /usr/local/bin/git --exec-path > > /usr/local/libexec/git-core > > $ > > > > Same path every time, sudo or not, full path to git or not. Just to verify, /usr/local/libexec/git-core/git-index-pack exists, and is executable? > Hmm, there is something fishy going on, and I am a bit frustrated not > being able to see what it is. > > The callpath should look like this: > > git.c::main() > -> setup_path() > -> cmd_clone() > -> transport_fetch_refs() > -> fetch_refs_via_pack() > -> fetch_pack() > -> do_fetch_pack() > -> get_pack() > -> start_command(), running either > "index-pack" or "unpack-objects" > on the incoming stream > > and start_command() forks and eventually does execv_git_cmd() which is a > thin wrapper around execvp(). > > The PATH exported when this execvp() runs should have been adjusted to > have the exec-path at the beginning by calling setup_path() and this is > done way before cmd_clone() was called by git.c::main() function. > > What am I not seeing? There should be something obvious that I am > missing. I do not see how your original command can fail with "exec > failed: No such file or directory". All I can think of is that this could happen if PATH already had git-index-pack, and the exec-path didn't have it. -Daniel *This .sig left intentionally blank* -- 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