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

Johannes Sixt· Jul 9, 2009, 08:06 UTC · lore

Jeff King schrieb:

Show 18 quoted lines

> Subject: [PATCH] Makefile: install 'git' in execdir
> 
> When a git command executes a subcommand, it uses the "git
> foo" form, which relies on finding "git" in the PATH.
> Normally this should not be a problem, since the same "git"
> that was used to invoke git in the first place will be
> found.  And if somebody invokes a "git" outside of the PATH
> (e.g., by giving its absolute path), this case is already
> covered: we put that absolute path onto the front of PATH.
> 
> However, if one is using "sudo", then sudo will execute the
> "git" from the PATH, but pass along a restricted PATH that
> may not contain the original "git" directory. In this case,
> executing a subcommand will fail.
> 
> To solve this, we put the "git" wrapper itself into the
> execdir; this directory is prepended to the PATH when git
> starts, so the wrapper will always be found.

I'd love to see this change justified not only by sudo, because this also helps another use-case where it avoids that between different vintages of git is switched:

Assume you have a git installed in prefix /usr and another one in prefix /home/j6t. PATH is /usr/bin:/bin. Consider this command:

   $ git --exec-path=/home/j6t/libexec/git-core gc

Then:

1. It runs /usr/bin/git with builtin gc.

2. It set PATH=/home/j6t/libexec/git-core:/usr/bin:/bin

3. builtin-gc runs git repack (no dash). It picks git-repack
   from /home/j6t. (PATH remains unchanged)

4. git-repack runs git pack-objects.

5. This picked /usr/bin/git and its builtin pack-objects

See how this switches from the version in /usr to /home/j6t and back to /usr?

With this change it switches from /usr to /home/j6t and remains there, which is "more correct", IMO (at least less surprising).

Notice that the problem is not only with --exec-path, but also with GIT_EXEC_PATH if somebody has it exported in .profile.

-- Hannes