{"thread":{"id":"20063","subject":"Re: \"fatal: index-pack failed\" on git-clone","startedAt":"2009-07-09T08:06:30Z","lastAt":"2009-07-09T08:06:30Z","messageCount":1,"participants":["Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117656","messageId":"mtranet.20090709100630.408099298@telekom.at","threadId":"20063","inReplyTo":null,"subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-07-09T08:06:30Z","receivedAt":"2009-07-09T08:06:30Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jeff King schrieb:\n> Subject: [PATCH] Makefile: install 'git' in execdir\n> \n> When a git command executes a subcommand, it uses the \"git\n> foo\" form, which relies on finding \"git\" in the PATH.\n> Normally this should not be a problem, since the same \"git\"\n> that was used to invoke git in the first place will be\n> found.  And if somebody invokes a \"git\" outside of the PATH\n> (e.g., by giving its absolute path), this case is already\n> covered: we put that absolute path onto the front of PATH.\n> \n> However, if one is using \"sudo\", then sudo will execute the\n> \"git\" from the PATH, but pass along a restricted PATH that\n> may not contain the original \"git\" directory. In this case,\n> executing a subcommand will fail.\n> \n> To solve this, we put the \"git\" wrapper itself into the\n> execdir; this directory is prepended to the PATH when git\n> starts, so the wrapper will always be found.\n\nI'd love to see this change justified not only by sudo, because\nthis also helps another use-case where it avoids that between\ndifferent vintages of git is switched:\n\nAssume you have a git installed in prefix /usr and another one\nin prefix /home/j6t. PATH is /usr/bin:/bin. Consider this command:\n\n   $ git --exec-path=/home/j6t/libexec/git-core gc\n\nThen:\n\n1. It runs /usr/bin/git with builtin gc.\n\n2. It set PATH=/home/j6t/libexec/git-core:/usr/bin:/bin\n\n3. builtin-gc runs git repack (no dash). It picks git-repack\n   from /home/j6t. (PATH remains unchanged)\n\n4. git-repack runs git pack-objects.\n\n5. This picked /usr/bin/git and its builtin pack-objects\n\nSee how this switches from the version in /usr to /home/j6t\nand back to /usr?\n\nWith this change it switches from /usr to /home/j6t and\nremains there, which is \"more correct\", IMO (at least\nless surprising).\n\nNotice that the problem is not only with --exec-path, but\nalso with GIT_EXEC_PATH if somebody has it exported\nin .profile.\n\n-- Hannes\n"}]}