{"thread":{"id":"20056","subject":"\"fatal: index-pack failed\" on git-clone","startedAt":"2009-07-08T15:58:48Z","lastAt":"2009-07-13T04:52:16Z","messageCount":18,"participants":["Fritz Anderson","Junio C Hamano","Daniel Barkalow","Johannes Sixt","Jeff King","Michael J Gruber","A Large Angry SCM"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117619","messageId":"C92DE6F3-4F35-469F-AC28-4DDD1D8105C2@uchicago.edu","threadId":"20056","inReplyTo":null,"subject":"\"fatal: index-pack failed\" on git-clone","fromName":"Fritz Anderson","fromEmail":"fritza@uchicago.edu","sentAt":"2009-07-08T15:58:48Z","receivedAt":"2009-07-08T15:58:48Z","isPatch":false,"sender":{"key":"fritza@uchicago.edu","avatar":null},"body":"I get the error \"fatal: index-pack failed\" when I attempt to clone a \nremote bare repository. The repository works well on other machines, \nincluding the repository's own.\n\nThe repository lives on a version of Mac OS X I'm not allowed to talk \nabout (I repeat: It works well for working copies on other machines, \nand on its own). The client is RHEL5. Git is version 1.6.3 on both \nmachines, and was built from the tarball.\n\nHere's the debug transcript:\n\n===========\n$ sudo GIT_TRACE=1 git clone myusername@remote.example.com:/Users/ \nmyusername/scientia/scientia.git\ntrace: built-in: git 'clone' 'myusername@remote.example.com:/Users/ \nmyusername/scientia/scientia.git'\nInitialized empty Git repository in /srv/scientia/.git/\ntrace: run_command: 'ssh' 'myusername@remote.example.com' 'git-upload- \npack '\\''/Users/myusername/scientia/scientia.git'\\'''\nPassword:\ntrace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '-- \nkeep=fetch-pack 17580 on local.example.com'\ntrace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '-- \nkeep=fetch-pack 17580 on local.example.com'\ntrace: exec failed: No such file or directory\ntrace: exec 'index-pack' failed: No such file or directory\nfatal: index-pack failed\nremote: Counting objects: 2797, done.\nremote: Compressing objects: 100% (2388/2388), done.\n$\n===========\n\n/Users/myusername/scientia/scientia.git on remote is a symlink to \na .git repository on another volume. I've verified that the path is \nvalid.\n\nOne post I saw via Google said that attempting to clone large files \ncan choke the process. I've done git-rm on my largest, reconstructable \nfiles, to no effect. (Though I suppose it does no good wrt the files \nthat are still in the history.)\n\nI've fooled around with git-verify-pack without result.\n\nPrior to all this, my last push to the repository failed with \n\"[rejected] ... non-fast forward\". I got past that with a \"git push -- \nforce\".\n\nHow can I get the clone done?\n\n\t— F\n"},{"id":"117620","messageId":"7viqi386th.fsf@alter.siamese.dyndns.org","threadId":"20056","inReplyTo":"C92DE6F3-4F35-469F-AC28-4DDD1D8105C2@uchicago.edu","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-08T16:42:34Z","receivedAt":"2009-07-08T16:42:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fritz Anderson writes:\n\n> I get the error \"fatal: index-pack failed\" when I attempt to clone a \n> remote bare repository. The repository works well on other machines, \n> including the repository's own.\n>\n> The repository lives on a version of Mac OS X I'm not allowed to talk \n> about (I repeat: It works well for working copies on other machines, \n> and on its own). The client is RHEL5. Git is version 1.6.3 on both \n> machines, and was built from the tarball.\n\nLooking at the output of the trace, I do not think that you have to worry\nabout people asking for a copy of your repository in order to diagnose\nthis issue, as I suspect that even a much smaller toy repository will fail\nfor you in the same way.\n\n> Here's the debug transcript:\n\n> ===========\n> $ sudo GIT_TRACE=1 git clone myusername@remote.example.com:/Users/ \n> myusername/scientia/scientia.git\n\nI have heard that pseudo resets the PATH so you are invoking \"git\" from\none of those standard system PATH, perhaps /usr/bin.\n\n> trace: built-in: git 'clone' 'myusername@remote.example.com:/Users/ \n> myusername/scientia/scientia.git'\n> Initialized empty Git repository in /srv/scientia/.git/\n> trace: run_command: 'ssh' 'myusername@remote.example.com' 'git-upload- \n> pack '\\''/Users/myusername/scientia/scientia.git'\\'''\n> Password:\n> trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '-- \n> keep=fetch-pack 17580 on local.example.com'\n> trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '-- \n> keep=fetch-pack 17580 on local.example.com'\n> trace: exec failed: No such file or directory\n> trace: exec 'index-pack' failed: No such file or directory\n\nThis is saying that \"git\" on the local side (the one you are running\n\"clone\" on) couldn't find its \"index-pack\" subcommand. Why?\n\nI think this is an issue with your RHEL5 box, not the MacOS box. A quick\ncheck that might be useful is to type:\n\n\t$ git index-pack\n\t$ sudo git index-pack\n"},{"id":"117621","messageId":"102A43B8-AD35-4B1D-850C-3642CEDB2864@uchicago.edu","threadId":"20056","inReplyTo":"7viqi386th.fsf@alter.siamese.dyndns.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Fritz Anderson","fromEmail":"fritza@uchicago.edu","sentAt":"2009-07-08T17:10:11Z","receivedAt":"2009-07-08T17:10:11Z","isPatch":false,"sender":{"key":"fritza@uchicago.edu","avatar":null},"body":"On Jul 8, 2009, at 11:42 AM, Junio C Hamano wrote:\n\n> Fritz Anderson writes:\n...\n>> $ sudo GIT_TRACE=1 git clone myusername@remote.example.com:/Users/\n>> myusername/scientia/scientia.git\n>\n> I have heard that pseudo resets the PATH so you are invoking \"git\" \n> from\n> one of those standard system PATH, perhaps /usr/bin.\n>\n>> trace: built-in: git 'clone' 'myusername@remote.example.com:/Users/\n>> myusername/scientia/scientia.git'\n>> Initialized empty Git repository in /srv/scientia/.git/\n>> trace: run_command: 'ssh' 'myusername@remote.example.com' 'git- \n>> upload-\n>> pack '\\''/Users/myusername/scientia/scientia.git'\\'''\n>> Password:\n>> trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '--\n>> keep=fetch-pack 17580 on local.example.com'\n>> trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '--\n>> keep=fetch-pack 17580 on local.example.com'\n>> trace: exec failed: No such file or directory\n>> trace: exec 'index-pack' failed: No such file or directory\n>\n> This is saying that \"git\" on the local side (the one you are running\n> \"clone\" on) couldn't find its \"index-pack\" subcommand. Why?\n>\n> I think this is an issue with your RHEL5 box, not the MacOS box. A \n> quick\n> check that might be useful is to type:\n>\n> \t$ git index-pack\n> \t$ sudo git index-pack\n\nHere is the result:\n\n===\n$ git index-pack\nusage: git index-pack [-v] [-o ] [{ ---keep | -- \nkeep= }] [--strict] { | --stdin [--fix-thin] [] }\n$ sudo git index-pack\nusage: git index-pack [-v] [-o ] [{ ---keep | -- \nkeep= }] [--strict] { | --stdin [--fix-thin] [] }\n===\n\nSo git is apparently found. HOWEVER, if I do this, it's a different \nstory:\n\n===\n$ which git\n/usr/local/bin/git\n$ sudo which git\nwhich: no git in (/usr/bin:/bin)\n===\n\nOn that evidence, I reissued my problem command under sudo, \nspecifying /usr/local/bin/git as the command. That worked. Thank you; \nI would not have found it without you.\n\nI'm obviously ignorant on the path issue, but that's off-topic for \nthis list.\n\nThanks again.\n\n\t— F\n"},{"id":"117623","messageId":"7vskh76pui.fsf@alter.siamese.dyndns.org","threadId":"20056","inReplyTo":"102A43B8-AD35-4B1D-850C-3642CEDB2864@uchicago.edu","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-08T17:34:29Z","receivedAt":"2009-07-08T17:34:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fritz Anderson writes:\n\n> Here is the result:\n>\n> ===\n> $ git index-pack\n> usage: git index-pack [-v] [-o ] [{ ---keep | -- \n> keep= }] [--strict] { | --stdin [--fix-thin] [ file>] }\n> $ sudo git index-pack\n> usage: git index-pack [-v] [-o ] [{ ---keep | -- \n> keep= }] [--strict] { | --stdin [--fix-thin] [ file>] }\n> ===\n>\n> So git is apparently found. HOWEVER, if I do this, it's a different \n> story:\n>\n> ===\n> $ which git\n> /usr/local/bin/git\n> $ sudo which git\n> which: no git in (/usr/bin:/bin)\n> ===\n\nI was told sudo does this path munging for security reasons (I do not use\nit personally) but it appears that it does _not_ do that for finding the\ntop level command in \"sudo $command $args\".\n\nVery interesting.\n\nWhich makes the initial \"sudo git clone...\" find git in _your_ path before\nsanitization (and that is why it even starts), but then the path is nuked\nfor the git process it launches, and we cannot find git-index-pack on the\nPATH.\n\nBut this should be fine, as git is expected to find git-index-pack in its\nGIT_EXEC_PATH that is compiled in the binary of \"git\" itself.\n\nWhich makes me suspect that your \"git\" in /usr/local/bin may be\nmisconfigured. You might want to check what these tell you.\n\n\t$ git --exec-path\n\t$ /usr/local/bin/git --exec-path\n"},{"id":"117625","messageId":"4103BA41-39E4-496F-A76F-17D84F30EA21@uchicago.edu","threadId":"20056","inReplyTo":"7vskh76pui.fsf@alter.siamese.dyndns.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Fritz Anderson","fromEmail":"fritza@uchicago.edu","sentAt":"2009-07-08T18:22:15Z","receivedAt":"2009-07-08T18:22:15Z","isPatch":false,"sender":{"key":"fritza@uchicago.edu","avatar":null},"body":"On Jul 8, 2009, at 12:34 PM, Junio C Hamano wrote:\n\n> Which makes the initial \"sudo git clone...\" find git in _your_ path \n> before\n> sanitization (and that is why it even starts), but then the path is \n> nuked\n> for the git process it launches, and we cannot find git-index-pack \n> on the\n> PATH.\n>\n> But this should be fine, as git is expected to find git-index-pack \n> in its\n> GIT_EXEC_PATH that is compiled in the binary of \"git\" itself.\n>\n> Which makes me suspect that your \"git\" in /usr/local/bin may be\n> misconfigured. You might want to check what these tell you.\n>\n> \t$ git --exec-path\n> \t$ /usr/local/bin/git --exec-path\n\nGlad to oblige. These are the four possibilities:\n\n$ git --exec-path\n/usr/local/libexec/git-core\n$ /usr/local/bin/git --exec-path\n/usr/local/libexec/git-core\n$ sudo git --exec-path\n/usr/local/libexec/git-core\n$ sudo /usr/local/bin/git --exec-path\n/usr/local/libexec/git-core\n$\n\nSame path every time, sudo or not, full path to git or not.\n\nI built git (after installing zlib) simply with \"./configure\" and \n\"sudo make install\".\n\n\t— F\n"},{"id":"117626","messageId":"7vd48b6md8.fsf@alter.siamese.dyndns.org","threadId":"20056","inReplyTo":"4103BA41-39E4-496F-A76F-17D84F30EA21@uchicago.edu","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-08T18:49:39Z","receivedAt":"2009-07-08T18:49:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fritz Anderson writes:\n\n> On Jul 8, 2009, at 12:34 PM, Junio C Hamano wrote:\n>\n>> Which makes the initial \"sudo git clone...\" find git in _your_ path\n>> before sanitization (and that is why it even starts), but then the path\n>> is nuked for the git process it launches, and we cannot find\n>> git-index-pack on the PATH.\n>>\n>> But this should be fine, as git is expected to find git-index-pack in\n>> its GIT_EXEC_PATH that is compiled in the binary of \"git\" itself.\n>>\n>> Which makes me suspect that your \"git\" in /usr/local/bin may be\n>> misconfigured. You might want to check what these tell you.\n>>\n>> \t$ git --exec-path\n>> \t$ /usr/local/bin/git --exec-path\n>\n> Glad to oblige. These are the four possibilities:\n>\n> $ git --exec-path\n> /usr/local/libexec/git-core\n> $ /usr/local/bin/git --exec-path\n> /usr/local/libexec/git-core\n> $ sudo git --exec-path\n> /usr/local/libexec/git-core\n> $ sudo /usr/local/bin/git --exec-path\n> /usr/local/libexec/git-core\n> $\n>\n> Same path every time, sudo or not, full path to git or not.\n\nHmm, there is something fishy going on, and I am a bit frustrated not\nbeing able to see what it is.\n\nThe callpath should look like this:\n\n git.c::main()\n -> setup_path()\n -> cmd_clone()\n -> transport_fetch_refs()\n -> fetch_refs_via_pack()\n -> fetch_pack()\n -> do_fetch_pack()\n -> get_pack()\n -> start_command(), running either\n \"index-pack\" or \"unpack-objects\"\n on the incoming stream\n\nand start_command() forks and eventually does execv_git_cmd() which is a\nthin wrapper around execvp().\n\nThe PATH exported when this execvp() runs should have been adjusted to\nhave the exec-path at the beginning by calling setup_path() and this is\ndone way before cmd_clone() was called by git.c::main() function.\n\nWhat am I not seeing? There should be something obvious that I am\nmissing. I do not see how your original command can fail with \"exec\nfailed: No such file or directory\".\n\nCould you try your original (non-working) command with this debug patch?\n\n exec_cmd.c | 9 +++++++--\n 1 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 408e4e5..000910b 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -101,6 +101,9 @@ void setup_path(void)\n \tconst char *old_path = getenv(\"PATH\");\n \tstruct strbuf new_path = STRBUF_INIT;\n \n+\ttrace_printf(\"trace: setup_path: the $PATH was: %s\\n\",\n+\t\t old_path ? old_path : \"NULL\");\n+\n \tadd_path(&new_path, git_exec_path());\n \tadd_path(&new_path, argv0_path);\n \n@@ -110,7 +113,8 @@ void setup_path(void)\n \t\tstrbuf_addstr(&new_path, \"/usr/local/bin:/usr/bin:/bin\");\n \n \tsetenv(\"PATH\", new_path.buf, 1);\n-\n+\ttrace_printf(\"trace: setup_path: the $PATH is now: %s\\n\",\n+\t\t getenv(\"PATH\") ? getenv(\"PATH\") : \"NULL\");\n \tstrbuf_release(&new_path);\n }\n \n@@ -138,7 +142,8 @@ int execv_git_cmd(const char **argv) {\n \texecvp(\"git\", (char **)nargv);\n \n \ttrace_printf(\"trace: exec failed: %s\\n\", strerror(errno));\n-\n+\ttrace_printf(\"trace: the $PATH was: %s\\n\",\n+\t\t getenv(\"PATH\") ? getenv(\"PATH\") : \"NULL\");\n \tfree(nargv);\n \treturn -1;\n }\n"},{"id":"117628","messageId":"alpine.LNX.2.00.0907081456570.2147@iabervon.org","threadId":"20056","inReplyTo":"7vd48b6md8.fsf@alter.siamese.dyndns.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-07-08T19:05:37Z","receivedAt":"2009-07-08T19:05:37Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 8 Jul 2009, Junio C Hamano wrote:\n\n> Fritz Anderson writes:\n> \n> > On Jul 8, 2009, at 12:34 PM, Junio C Hamano wrote:\n> >\n> >> Which makes the initial \"sudo git clone...\" find git in _your_ path\n> >> before sanitization (and that is why it even starts), but then the path\n> >> is nuked for the git process it launches, and we cannot find\n> >> git-index-pack on the PATH.\n> >>\n> >> But this should be fine, as git is expected to find git-index-pack in\n> >> its GIT_EXEC_PATH that is compiled in the binary of \"git\" itself.\n> >>\n> >> Which makes me suspect that your \"git\" in /usr/local/bin may be\n> >> misconfigured. You might want to check what these tell you.\n> >>\n> >> \t$ git --exec-path\n> >> \t$ /usr/local/bin/git --exec-path\n> >\n> > Glad to oblige. These are the four possibilities:\n> >\n> > $ git --exec-path\n> > /usr/local/libexec/git-core\n> > $ /usr/local/bin/git --exec-path\n> > /usr/local/libexec/git-core\n> > $ sudo git --exec-path\n> > /usr/local/libexec/git-core\n> > $ sudo /usr/local/bin/git --exec-path\n> > /usr/local/libexec/git-core\n> > $\n> >\n> > Same path every time, sudo or not, full path to git or not.\n\nJust to verify, /usr/local/libexec/git-core/git-index-pack exists, and is \nexecutable?\n\n> Hmm, there is something fishy going on, and I am a bit frustrated not\n> being able to see what it is.\n> \n> The callpath should look like this:\n> \n> git.c::main()\n> -> setup_path()\n> -> cmd_clone()\n> -> transport_fetch_refs()\n> -> fetch_refs_via_pack()\n> -> fetch_pack()\n> -> do_fetch_pack()\n> -> get_pack()\n> -> start_command(), running either\n> \"index-pack\" or \"unpack-objects\"\n> on the incoming stream\n> \n> and start_command() forks and eventually does execv_git_cmd() which is a\n> thin wrapper around execvp().\n> \n> The PATH exported when this execvp() runs should have been adjusted to\n> have the exec-path at the beginning by calling setup_path() and this is\n> done way before cmd_clone() was called by git.c::main() function.\n> \n> What am I not seeing? There should be something obvious that I am\n> missing. I do not see how your original command can fail with \"exec\n> failed: No such file or directory\".\n\nAll I can think of is that this could happen if PATH already had \ngit-index-pack, and the exec-path didn't have it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"117631","messageId":"CCB253F1-66A4-4B69-AC5F-89FB792FACBB@uchicago.edu","threadId":"20056","inReplyTo":"alpine.LNX.2.00.0907081456570.2147@iabervon.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Fritz Anderson","fromEmail":"fritza@uchicago.edu","sentAt":"2009-07-08T20:05:52Z","receivedAt":"2009-07-08T20:05:52Z","isPatch":false,"sender":{"key":"fritza@uchicago.edu","avatar":null},"body":"On Jul 8, 2009, at 2:05 PM, Daniel Barkalow wrote:\n\n> On Wed, 8 Jul 2009, Junio C Hamano wrote:\n>\n>> Fritz Anderson writes:\n...\n>>> Glad to oblige. These are the four possibilities:\n>>>\n>>> $ git --exec-path\n>>> /usr/local/libexec/git-core\n>>> $ /usr/local/bin/git --exec-path\n>>> /usr/local/libexec/git-core\n>>> $ sudo git --exec-path\n>>> /usr/local/libexec/git-core\n>>> $ sudo /usr/local/bin/git --exec-path\n>>> /usr/local/libexec/git-core\n>>> $\n>>>\n>>> Same path every time, sudo or not, full path to git or not.\n>\n> Just to verify, /usr/local/libexec/git-core/git-index-pack exists, \n> and is\n> executable?\n\n$ ls -l /usr/local/libexec/git-core/git-index-pack\n-rwxr-xr-x 1 root root 1700975 Jul 8 09:28 /usr/local/libexec/git- \ncore/git-index-pack\n\nExists, and is executable.\n\n\t— F\n"},{"id":"117632","messageId":"7A134415-D275-4638-9674-5BCC18A14BC4@uchicago.edu","threadId":"20056","inReplyTo":"7vd48b6md8.fsf@alter.siamese.dyndns.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Fritz Anderson","fromEmail":"fritza@uchicago.edu","sentAt":"2009-07-08T20:23:19Z","receivedAt":"2009-07-08T20:23:19Z","isPatch":false,"sender":{"key":"fritza@uchicago.edu","avatar":null},"body":"On Jul 8, 2009, at 1:49 PM, Junio C Hamano wrote:\n\n> Could you try your original (non-working) command with this debug \n> patch?\n\n\n(I had to apply the patch by hand; RHEL patch complained about a \nmalformatted patch file.)\n\n=====\n$ sudo GIT_TRACE=1 git clone username@remote.example.com:/Users/ \nusername/scientia/scientia.git\ntrace: setup_path: the $PATH was: /usr/bin:/bin\ntrace: setup_path: the $PATH is now: /usr/local/libexec/git-core:/usr/ \nbin:/bin\ntrace: built-in: git 'clone' 'username@remote.example.com:/Users/ \nusername/scientia/scientia.git'\nInitialized empty Git repository in /home/username/git-1.6.3/ \nscientia/.git/\ntrace: run_command: 'ssh' 'username@remote.example.com' 'git-upload- \npack '\\''/Users/username/scientia/scientia.git'\\'''\nPassword:\ntrace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '-- \nkeep=fetch-pack 32503 on scientia.uchicago.edu'\ntrace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '-- \nkeep=fetch-pack 32503 on scientia.uchicago.edu'\ntrace: exec failed: No such file or directory\ntrace: the $PATH was: /usr/local/libexec/git-core:/usr/bin:/bin\ntrace: exec 'index-pack' failed: No such file or directory\nfatal: index-pack failed\nremote: Counting objects: 2802, done.\nremote: Compressing objects: 100% (2393/2393), done.\n=====\n\nAs a reminder:\n=====\n$ sudo /usr/local/bin/git --exec-path\n/usr/local/libexec/git-core\n=====\n\n\t— F\n"},{"id":"117633","messageId":"200907082242.51495.j6t@kdbg.org","threadId":"20056","inReplyTo":"7vd48b6md8.fsf@alter.siamese.dyndns.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-07-08T20:42:51Z","receivedAt":"2009-07-08T20:42:51Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Mittwoch, 8. Juli 2009, Junio C Hamano wrote:\n> The PATH exported when this execvp() runs should have been adjusted to\n> have the exec-path at the beginning by calling setup_path() and this is\n> done way before cmd_clone() was called by git.c::main() function.\n>\n> What am I not seeing? There should be something obvious that I am\n> missing. I do not see how your original command can fail with \"exec\n> failed: No such file or directory\".\n\nIt failed because /usr/local/bin is not in the PATH when git is run with sudo. \nLook at the original trace output:\n\n> $ sudo GIT_TRACE=1 git clone ...\n\nAt this point PATH is \"/bin:/usr/bin\" and the invoked git \nis /usr/local/bin/git (appearently!).\n\n> trace: built-in: git 'clone' ...\n> Initialized empty Git repository in /srv/scientia/.git/\n> trace: run_command: 'ssh' ... 'git-upload-pack ...\n> Password:\n\nAt this point PATH is \"/usr/local/libexec/git-core:/bin:/usr/bin\". There is \nno /usr/local/bin.\n\n> trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' ...\n> trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' ...\n\nThe PATH doesn't have 'git'; this must fail.\n\n> trace: exec failed: No such file or directory\n> trace: exec 'index-pack' failed: No such file or directory\n> fatal: index-pack failed\n\nHowever, if Fritz runs 'sudo /usr/local/bin/git clone ...', then the interim \nPATH is \"/usr/local/bin:/usr/local/libexec/git-core:/bin:/usr/bin\" because \nthis time setup_path() finds a non-empty argv0_path, and the command works.\n\n-- Hannes\n"},{"id":"117635","messageId":"20090708211201.GA21600@coredump.intra.peff.net","threadId":"20056","inReplyTo":"200907082242.51495.j6t@kdbg.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-08T21:12:01Z","receivedAt":"2009-07-08T21:12:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 08, 2009 at 10:42:51PM +0200, Johannes Sixt wrote:\n\n> At this point PATH is \"/usr/local/libexec/git-core:/bin:/usr/bin\". There is \n> no /usr/local/bin.\n> \n> > trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' ...\n> > trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' ...\n> \n> The PATH doesn't have 'git'; this must fail.\n> \n> > trace: exec failed: No such file or directory\n> > trace: exec 'index-pack' failed: No such file or directory\n> > fatal: index-pack failed\n\nI think there are two possible improvements here:\n\n 1. Hardlinking \"git\" into exec-path. That means we will always be able\n to find the wrapper, even if the PATH has been munged. Admittedly,\n it sounds far fetched to me that something would exec from the PATH\n and then munge the PATH afterwards, but that seems to be what sudo\n is doing (and it is pretty commonly used).\n\n 2. Better error messages. This would have been much more obvious to\n diagnose if it had said:\n\n trace: exec(\"git\") failed: No such file or directory\n\n Johannes, I saw you just posted some related improvements to\n run_command; do they improve this?\n\n-Peff\n"},{"id":"117637","messageId":"47A38129-92A6-4CA5-8B79-E93CE9BF867B@uchicago.edu","threadId":"20056","inReplyTo":"20090708211201.GA21600@coredump.intra.peff.net","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Fritz Anderson","fromEmail":"fritza@uchicago.edu","sentAt":"2009-07-08T21:27:42Z","receivedAt":"2009-07-08T21:27:42Z","isPatch":false,"sender":{"key":"fritza@uchicago.edu","avatar":null},"body":"On Jul 8, 2009, at 4:12 PM, Jeff King wrote:\n\n> 1. Hardlinking \"git\" into exec-path. That means we will always be \n> able\n> to find the wrapper, even if the PATH has been munged. Admittedly,\n> it sounds far fetched to me that something would exec from the \n> PATH\n> and then munge the PATH afterwards, but that seems to be what sudo\n> is doing (and it is pretty commonly used).\n\nHere's an interesting experiment (RHEL 5):\n\n=====\n$ echo $PATH\n/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/fritza/bin\n$ cat >tryme.sh\necho $PATH\n$ chmod a+x tryme.sh\n$ sudo ./tryme.sh\n/usr/bin:/bin\n\n$ sudo git --exec-path\n/usr/local/libexec/git-core\n$ cat >tryme.sh\ngit --exec-path\n$ ./tryme.sh\n/usr/local/libexec/git-core\n$ sudo ./tryme.sh\n./tryme.sh: line 1: git: command not found\n=====\n\nThat is to say, possibly there is some sudo magic that uses the \ninvoker's PATH to find the command in the first argument. After that, \nhowever, PATH is a \"safe\" value. So if you invoke git via sudo, it \nwill internally see a PATH different from the one at the time of \ninvocation.\n\nFor what it's worth.\n\n\t— F\n"},{"id":"117639","messageId":"7vvdm26bbk.fsf@alter.siamese.dyndns.org","threadId":"20056","inReplyTo":"200907082242.51495.j6t@kdbg.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-08T22:48:15Z","receivedAt":"2009-07-08T22:48:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> However, if Fritz runs 'sudo /usr/local/bin/git clone ...', then the interim \n> PATH is \"/usr/local/bin:/usr/local/libexec/git-core:/bin:/usr/bin\" because \n> this time setup_path() finds a non-empty argv0_path, and the command works.\n\nAhh, that is what I was missing.\n\nAs I said elsewhere already, I personally do not think sudo is worth\nsupporting compared to the cost of this kind of pain resulting from its\nmisguided \"safety\" brokenness, but apparently it is widely used. I think\nwhat Peff suggests in this thread might be a reasonable workaround.\n"},{"id":"117650","messageId":"20090709063735.GA22544@coredump.intra.peff.net","threadId":"20056","inReplyTo":"7vvdm26bbk.fsf@alter.siamese.dyndns.org","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-09T06:37:35Z","receivedAt":"2009-07-09T06:37:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 08, 2009 at 03:48:15PM -0700, Junio C Hamano wrote:\n\n> > However, if Fritz runs 'sudo /usr/local/bin/git clone ...', then the interim \n> > PATH is \"/usr/local/bin:/usr/local/libexec/git-core:/bin:/usr/bin\" because \n> > this time setup_path() finds a non-empty argv0_path, and the command works.\n> \n> Ahh, that is what I was missing.\n> \n> As I said elsewhere already, I personally do not think sudo is worth\n> supporting compared to the cost of this kind of pain resulting from its\n> misguided \"safety\" brokenness, but apparently it is widely used. I think\n> what Peff suggests in this thread might be a reasonable workaround.\n\nYes, I find sudo's restrictions silly, considering that most people use\nit to allow arbitrary code execution, which is why I wrote this some\ntime ago:\n\n http://peff.net/tinysu/\n\nHowever, sudo is pretty popular, and it should be easy enough for us to\nwork around it in this case. Patch is below. It's longer than the\none-liner necessary, because it now uses \"git\" as the magic \"everything\nshould link to this\" file instead of \"git-add\", which I think is a bit\nmore obvious.\n\n-- >8 --\nSubject: [PATCH] Makefile: install 'git' in execdir\n\nWhen a git command executes a subcommand, it uses the \"git\nfoo\" form, which relies on finding \"git\" in the PATH.\nNormally this should not be a problem, since the same \"git\"\nthat was used to invoke git in the first place will be\nfound. And if somebody invokes a \"git\" outside of the PATH\n(e.g., by giving its absolute path), this case is already\ncovered: we put that absolute path onto the front of PATH.\n\nHowever, if one is using \"sudo\", then sudo will execute the\n\"git\" from the PATH, but pass along a restricted PATH that\nmay not contain the original \"git\" directory. In this case,\nexecuting a subcommand will fail.\n\nTo solve this, we put the \"git\" wrapper itself into the\nexecdir; this directory is prepended to the PATH when git\nstarts, so the wrapper will always be found.\n\nSigned-off-by: Jeff King \n---\n Makefile | 14 +++++++-------\n 1 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 78cc113..311ce7d 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1641,15 +1641,15 @@ ifneq (,$X)\n endif\n \tbindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \\\n \texecdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \\\n-\t{ $(RM) \"$$execdir/git-add$X\" && \\\n+\t{ $(RM) \"$$execdir/git$X\" && \\\n \t\ttest -z \"$(NO_CROSS_DIRECTORY_HARDLINKS)\" && \\\n-\t\tln \"$$bindir/git$X\" \"$$execdir/git-add$X\" 2>/dev/null || \\\n-\t\tcp \"$$bindir/git$X\" \"$$execdir/git-add$X\"; } && \\\n-\t{ for p in $(filter-out git-add$X,$(BUILT_INS)); do \\\n+\t\tln \"$$bindir/git$X\" \"$$execdir/git$X\" 2>/dev/null || \\\n+\t\tcp \"$$bindir/git$X\" \"$$execdir/git$X\"; } && \\\n+\t{ for p in $(BUILT_INS); do \\\n \t\t$(RM) \"$$execdir/$$p\" && \\\n-\t\tln \"$$execdir/git-add$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n-\t\tln -s \"git-add$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n-\t\tcp \"$$execdir/git-add$X\" \"$$execdir/$$p\" || exit; \\\n+\t\tln \"$$execdir/git$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n+\t\tln -s \"git$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n+\t\tcp \"$$execdir/git$X\" \"$$execdir/$$p\" || exit; \\\n \t done; } && \\\n \t./check_bindir \"z$$bindir\" \"z$$execdir\" \"$$bindir/git-add$X\"\n \n-- \n1.6.3.3.529.g74caa.dirty\n"},{"id":"117660","messageId":"4A55AD6E.8080200@drmicha.warpmail.net","threadId":"20056","inReplyTo":"20090709063735.GA22544@coredump.intra.peff.net","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-07-09T08:42:22Z","receivedAt":"2009-07-09T08:42:22Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 09.07.2009 08:37:\n> On Wed, Jul 08, 2009 at 03:48:15PM -0700, Junio C Hamano wrote:\n> \n>>> However, if Fritz runs 'sudo /usr/local/bin/git clone ...', then the interim \n>>> PATH is \"/usr/local/bin:/usr/local/libexec/git-core:/bin:/usr/bin\" because \n>>> this time setup_path() finds a non-empty argv0_path, and the command works.\n>>\n>> Ahh, that is what I was missing.\n>>\n>> As I said elsewhere already, I personally do not think sudo is worth\n>> supporting compared to the cost of this kind of pain resulting from its\n>> misguided \"safety\" brokenness, but apparently it is widely used. I think\n>> what Peff suggests in this thread might be a reasonable workaround.\n> \n> Yes, I find sudo's restrictions silly, considering that most people use\n> it to allow arbitrary code execution, which is why I wrote this some\n> time ago:\n> \n> http://peff.net/tinysu/\n> \n\n:)\n\nI think writing \"tinysu\" is really the best statement one can make about\n\"sudo\"... although \"sudoh\" would have been the most appropriate name...\n\nYour patch is welcome, of course, and also removes the somewhat\nsurprising special role played by \"git-add\".\n\nMichael\n"},{"id":"117714","messageId":"200907092011.45302.j6t@kdbg.org","threadId":"20056","inReplyTo":"20090708211201.GA21600@coredump.intra.peff.net","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-07-09T18:11:44Z","receivedAt":"2009-07-09T18:11:44Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Mittwoch, 8. Juli 2009, Jeff King wrote:\n> 2. Better error messages. This would have been much more obvious to\n> diagnose if it had said:\n>\n> trace: exec(\"git\") failed: No such file or directory\n>\n> Johannes, I saw you just posted some related improvements to\n> run_command; do they improve this?\n\nNo.\n\n-- Hannes\n"},{"id":"117735","messageId":"4A567D57.7060602@gmail.com","threadId":"20056","inReplyTo":"20090709063735.GA22544@coredump.intra.peff.net","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-07-09T23:29:27Z","receivedAt":"2009-07-09T23:29:27Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jeff King wrote:\n\n >\n > Signed-off-by: Jeff King \n > ---\n > Makefile | 14 +++++++-------\n > 1 files changed, 7 insertions(+), 7 deletions(-)\n >\n > diff --git a/Makefile b/Makefile\n > index 78cc113..311ce7d 100644\n > --- a/Makefile\n > +++ b/Makefile\n > @@ -1641,15 +1641,15 @@ ifneq (,$X)\n > endif\n > \tbindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \\\n > \texecdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \\\n > -\t{ $(RM) \"$$execdir/git-add$X\" && \\\n > +\t{ $(RM) \"$$execdir/git$X\" && \\\n > \t\ttest -z \"$(NO_CROSS_DIRECTORY_HARDLINKS)\" && \\\n > -\t\tln \"$$bindir/git$X\" \"$$execdir/git-add$X\" 2>/dev/null || \\\n > -\t\tcp \"$$bindir/git$X\" \"$$execdir/git-add$X\"; } && \\\n > -\t{ for p in $(filter-out git-add$X,$(BUILT_INS)); do \\\n > +\t\tln \"$$bindir/git$X\" \"$$execdir/git$X\" 2>/dev/null || \\\n > +\t\tcp \"$$bindir/git$X\" \"$$execdir/git$X\"; } && \\\n > +\t{ for p in $(BUILT_INS); do \\\n > \t\t$(RM) \"$$execdir/$$p\" && \\\n > -\t\tln \"$$execdir/git-add$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n > -\t\tln -s \"git-add$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n > -\t\tcp \"$$execdir/git-add$X\" \"$$execdir/$$p\" || exit; \\\n > +\t\tln \"$$execdir/git$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n > +\t\tln -s \"git$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n > +\t\tcp \"$$execdir/git$X\" \"$$execdir/$$p\" || exit; \\\n > \t done; } && \\\n > \t./check_bindir \"z$$bindir\" \"z$$execdir\" \"$$bindir/git-add$X\"\n >\n\nThis breaks the install if ${bindir} == ${execdir}. The following is \nneeded on top Peff's patch.\n\ndiff --git a/Makefile b/Makefile\nindex 311ce7d..ec0fddf 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1641,10 +1641,11 @@ ifneq (,$X)\n endif\n \tbindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \\\n \texecdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \\\n-\t{ $(RM) \"$$execdir/git$X\" && \\\n-\t\ttest -z \"$(NO_CROSS_DIRECTORY_HARDLINKS)\" && \\\n-\t\tln \"$$bindir/git$X\" \"$$execdir/git$X\" 2>/dev/null || \\\n-\t\tcp \"$$bindir/git$X\" \"$$execdir/git$X\"; } && \\\n+\t{ test \"$$bindir/git$X\" = \"$$execdir/git$X\" || \\\n+\t\t{ $(RM) \"$$execdir/git$X\" && \\\n+\t\t\ttest -z \"$(NO_CROSS_DIRECTORY_HARDLINKS)\" && \\\n+\t\t\tln \"$$bindir/git$X\" \"$$execdir/git$X\" 2>/dev/null || \\\n+\t\t\tcp \"$$bindir/git$X\" \"$$execdir/git$X\"; } } && \\\n \t{ for p in $(BUILT_INS); do \\\n \t\t$(RM) \"$$execdir/$$p\" && \\\n \t\tln \"$$execdir/git$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n"},{"id":"117884","messageId":"20090713045215.GC8407@coredump.intra.peff.net","threadId":"20056","inReplyTo":"4A567D57.7060602@gmail.com","subject":"Re: \"fatal: index-pack failed\" on git-clone","fromName":"Jeff King","fromEmail":"peff@cc.gatech.edu","sentAt":"2009-07-13T04:52:16Z","receivedAt":"2009-07-13T04:52:16Z","isPatch":false,"sender":{"key":"peff@cc.gatech.edu","avatar":null},"body":"On Thu, Jul 09, 2009 at 07:29:27PM -0400, A Large Angry SCM wrote:\n\n> This breaks the install if ${bindir} == ${execdir}. The following is\n> needed on top Peff's patch.\n\nOops, I didn't even think to test that (and then I left town all weekend\nleaving you to pick up the pieces...:) ). Thanks.\n \n-Peff\n"}]}