I just noticed that my copy of git-daemon running from xinetd on Red
Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.
On the client side this is what you see ("git clone" used in the
example but you get the same issue with "git ls-remote"):
git clone git://git.wincent.com/wikitext.git
Initialized empty Git repository in /tmp/wikitext/.git/
fatal: The remote end hung up unexpectedly
fetch-pack from 'git://git.wincent.com/wikitext.git' failed.
Nothing printed to the logs on the server side: it simply hangs up. By
connecting via telnet I've confirmed that git-daemon is running and
does accept the initial connection.
The verdict according to "git bisect" is that
511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:
commit 511707d42b3b3e57d9623493092590546ffeae80
Author: Scott R Parish <srp@xxxxxxxxxxxx>
Date: Sun Oct 28 04:17:20 2007 -0700
use only the $PATH for exec'ing git commands
We need to correctly set up $PATH for non-c based git commands.
Since we already do this, we can just use that $PATH and execvp,
instead of looping over the paths with execve.
This patch adds a setup_path() function to exec_cmd.c, which sets
the $PATH order correctly for our search order. execv_git_cmd() is
stripped down to setting up argv and calling execvp(). git.c's
main() only only needs to call setup_path().
Signed-off-by: Scott R Parish <srp@xxxxxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
:100644 100644 33b17a6b45699e73a9b58f0ff02135eae913b47d
2d0a75851284392aa8ae44bc486df6a034d0af13 M exec_cmd.c
:100644 100644 da99287552b5d3eafc495f998a936df81ee3f8b9
a892355c8212298130fb3925c6cba352ed6999b6 M exec_cmd.h
:100644 100644 c7cabf5f348118f318d7c3abe55853b576869a98
4e10581101c26444da5c7c44a80219b11607705b M git.c
Does that look like it might be the issue? Anyone familiar with that
part of the code care to comment? Any other info I can provide that
might shed light on the problem?
Cheers,
Wincent
-
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
