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

Jeff King schrieb:

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