On Mittwoch, 8. Juli 2009, Junio C Hamano wrote: > The PATH exported when this execvp() runs should have been adjusted to > have the exec-path at the beginning by calling setup_path() and this is > done way before cmd_clone() was called by git.c::main() function. > > What am I not seeing? There should be something obvious that I am > missing. I do not see how your original command can fail with "exec > failed: No such file or directory". It failed because /usr/local/bin is not in the PATH when git is run with sudo. Look at the original trace output: > $ sudo GIT_TRACE=1 git clone ... At this point PATH is "/bin:/usr/bin" and the invoked git is /usr/local/bin/git (appearently!). > trace: built-in: git 'clone' ... > Initialized empty Git repository in /srv/scientia/.git/ > trace: run_command: 'ssh' ... 'git-upload-pack ... > Password: At this point PATH is "/usr/local/libexec/git-core:/bin:/usr/bin". There is no /usr/local/bin. > trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' ... > trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' ... The PATH doesn't have 'git'; this must fail. > trace: exec failed: No such file or directory > trace: exec 'index-pack' failed: No such file or directory > fatal: index-pack failed However, if Fritz runs 'sudo /usr/local/bin/git clone ...', then the interim PATH is "/usr/local/bin:/usr/local/libexec/git-core:/bin:/usr/bin" because this time setup_path() finds a non-empty argv0_path, and the command works. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html