Re: "fatal: index-pack failed" on git-clone

> Fritz Anderson <fritza@uchicago.edu> 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.

> 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".