connect: treat generic proxy processes like ssh processes
authorJeff King <peff@peff.net>
Mon, 16 May 2011 06:46:07 +0000 (02:46 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 16 May 2011 23:20:01 +0000 (16:20 -0700)
commit5cbf8246d2e68470648d123e356665fca9ffca73
treecfde44d8294c3867be28d2e38ec52f80530182c6
parent61432146ad707e969664c0151364e2d8da9fb157
connect: treat generic proxy processes like ssh processes

The git_connect function returns two ends of a pipe for
talking with a remote, plus a struct child_process
representing the other end of the pipe. If we have a direct
socket connection, then this points to a special "no_fork"
child process.

The code path for doing git-over-pipes or git-over-ssh sets
up this child process to point to the child git command or
the ssh process. When we call finish_connect eventually, we
check wait() on the command and report its return value.

The code path for git://, on the other hand, always sets it
to no_fork. In the case of a direct TCP connection, this
makes sense; we have no child process. But in the case of a
proxy command (configured by core.gitproxy), we do have a
child process, but we throw away its pid, and therefore
ignore its return code.

Instead, let's keep that information in the proxy case, and
respect its return code, which can help catch some errors
(though depending on your proxy command, it will be errors
reported by the proxy command itself, and not propagated
from git commands. Still, it is probably better to propagate
such errors than to ignore them).

It also means that the child_process field can reliably be
used to determine whether the returned descriptors are
actually a full-duplex socket, which means we should be
using shutdown() instead of a simple close.

Signed-off-by: Jeff King <peff@peff.net>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
connect.c