summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 9319789)
raw | patch | inline | side by side (parent: 9319789)
author | Jeff King <peff@peff.net> | |
Wed, 2 Sep 2009 06:36:47 +0000 (02:36 -0400) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Thu, 3 Sep 2009 01:39:02 +0000 (18:39 -0700) |
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>
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>
builtin-clone.c | patch | blob | history | |
t/t5601-clone.sh | patch | blob | history |
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910b1c76f3c994e4a22c9c0a1da38843e050..1c1d72911757c116b0cd19dd4b50c10ebbd68214 100644 (file)
--- a/builtin-clone.c
+++ b/builtin-clone.c
option_no_checkout = 1;
}
- if (transport)
+ if (transport) {
transport_unlock_pack(transport);
+ transport_disconnect(transport);
+ }
if (!option_no_checkout) {
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 44793f2eee0e0c14802ecedfe0637cc6855f51b6..c3ffc8f15c6165713e29fecacdd0f335aba1d56c 100755 (executable)
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
(
cd src-0 && git init
) &&
- git clone src-0 target-6 &&
+ git clone "file://$(pwd)/src-0" target-6 2>err-6 &&
+ ! grep "fatal:" err-6 &&
(
cd src-0 && test_commit A
) &&
- git clone src-0 target-7 &&
+ git clone "file://$(pwd)/src-0" target-7 2>err-7 &&
+ ! grep "fatal:" err-7 &&
# There is no reason to insist they are bit-for-bit
# identical, but this test should suffice for now.
test_cmp target-6/.git/config target-7/.git/config