From ca8e127c9bd65b07a565ca00aff8e0a48628bfc3 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Fri, 10 Aug 2012 03:57:31 -0400 Subject: [PATCH] send-pack: fix capability-sending logic If we have capabilities to send to the server, we send the regular "want" line followed by a NUL, then the capabilities; otherwise, we do not even send the NUL. However, when checking whether we want to send the "quiet" capability, we check args->quiet, which is wrong. That flag only tells us whether the client side wanted to be quiet, not whether the server supports it (originally, in c207e34f, it meant both; however, that was later split into two flags by 01fdc21f). We still check the right flag when actually printing "quiet", so this could only have two effects: 1. We might send the trailing NUL when we do not otherwise need to. In theory, an antique pre-capability implementation of git might choke on this (since the client is instructed never to respond with capabilities that the server has not first advertised). 2. We might also want to send the quiet flag if the args->progress flag is false, but this code path would not trigger in that instance. In practice, it almost certainly never matters. The report-status capability dates back to 2005. Any real-world server is going to advertise that, and we will always respond with at least that capability. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- builtin/send-pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/send-pack.c b/builtin/send-pack.c index c4d42113c2..5c69995552 100644 --- a/builtin/send-pack.c +++ b/builtin/send-pack.c @@ -306,7 +306,7 @@ int send_pack(struct send_pack_args *args, char *new_hex = sha1_to_hex(ref->new_sha1); int quiet = quiet_supported && (args->quiet || !args->progress); - if (!cmds_sent && (status_report || use_sideband || args->quiet)) { + if (!cmds_sent && (status_report || use_sideband || quiet)) { packet_buf_write(&req_buf, "%s %s %s%c%s%s%s agent=%s", old_hex, new_hex, ref->name, 0, -- 2.11.4.GIT