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

From: Fritz Anderson <fritza@uchicago.edu>
Date: Jul 8, 2009, 21:27 UTC
Message-ID: <47A38129-92A6-4CA5-8B79-E93CE9BF867B@uchicago.edu>
In-Reply-To: <20090708211201.GA21600@coredump.intra.peff.net>

On Jul 8, 2009, at 4:12 PM, Jeff King wrote:

Show 7 quoted lines

>  1. Hardlinking "git" into exec-path. That means we will always be  
> able
>     to find the wrapper, even if the PATH has been munged. Admittedly,
>     it sounds far fetched to me that something would exec from the  
> PATH
>     and then munge the PATH afterwards, but that seems to be what sudo
>     is doing (and it is pretty commonly used).

Here's an interesting experiment (RHEL 5):

===== $ echo $PATH /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/fritza/bin $ cat >tryme.sh echo $PATH $ chmod a+x tryme.sh $ sudo ./tryme.sh /usr/bin:/bin

$ sudo git --exec-path /usr/local/libexec/git-core $ cat >tryme.sh git --exec-path $ ./tryme.sh /usr/local/libexec/git-core $ sudo ./tryme.sh ./tryme.sh: line 1: git: command not found =====

That is to say, possibly there is some sudo magic that uses the invoker's PATH to find the command in the first argument. After that, however, PATH is a "safe" value. So if you invoke git via sudo, it will internally see a PATH different from the one at the time of invocation.

For what it's worth.

	— F