summaryrefslogtreecommitdiff
path: root/git_remote_helpers
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2009-09-02 02:36:47 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2009-09-02 18:39:02 -0700
commit12d4996622f524e61cbf855b32600150a8c94c02 (patch)
treea4370304dd770fb01e7673b2d98d35052268b476 /git_remote_helpers
parentFix overridable written with an extra 'e' (diff)
downloadtgif-12d4996622f524e61cbf855b32600150a8c94c02.tar.xz
clone: disconnect transport after fetching
The current code just leaves the transport in whatever state it was in after performing the fetch. For a non-empty clone over the git protocol, the transport code already disconnects at the end of the fetch. But for an empty clone, we leave the connection hanging, and eventually close the socket when clone exits. This causes the remote upload-pack to complain "the remote end hung up unexpectedly". While this message is harmless to the clone itself, it is unnecessarily scary for a user to see and may pollute git-daemon logs. This patch just explicitly calls disconnect after we are done with the remote end, which sends a flush packet to upload-pack and cleanly disconnects, avoiding the error message. Other transports are unaffected or slightly improved: - for a non-empty repo over the git protocol, the second disconnect is a no-op (since we are no longer connected) - for "walker" transports (like HTTP or FTP), we actually free some used memory (which previously just sat until the clone process exits) - for "rsync", disconnect is always a no-op anyway Signed-off-by: Jeff King <peff@peff.net> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git_remote_helpers')
0 files changed, 0 insertions, 0 deletions