summaryrefslogtreecommitdiff
path: root/send-pack.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2013-02-20 15:02:28 -0500
committerJunio C Hamano <gitster@pobox.com>2013-02-20 13:42:21 -0800
commit819b929d3389f6007e1c469d9060e7876caeb97f (patch)
treea978fc00c1d271cd00b910c3e4a6dc864ea7de55 /send-pack.c
parent0380942902b23f02f7f595bc394e09bcd74d4ded (diff)
downloadgit-819b929d3389f6007e1c469d9060e7876caeb97f.tar.gz
pkt-line: teach packet_read_line to chomp newlines
The packets sent during ref negotiation are all terminated by newline; even though the code to chomp these newlines is short, we end up doing it in a lot of places. This patch teaches packet_read_line to auto-chomp the trailing newline; this lets us get rid of a lot of inline chomping code. As a result, some call-sites which are not reading line-oriented data (e.g., when reading chunks of packfiles alongside sideband) transition away from packet_read_line to the generic packet_read interface. This patch converts all of the existing callsites. Since the function signature of packet_read_line does not change (but its behavior does), there is a possibility of new callsites being introduced in later commits, silently introducing an incompatibility. However, since a later patch in this series will change the signature, such a commit would have to be merged directly into this commit, not to the tip of the series; we can therefore ignore the issue. This is an internal cleanup and should produce no change of behavior in the normal case. However, there is one corner case to note. Callers of packet_read_line have never been able to tell the difference between a flush packet ("0000") and an empty packet ("0004"), as both cause packet_read_line to return a length of 0. Readers treat them identically, even though Documentation/technical/protocol-common.txt says we must not; it also says that implementations should not send an empty pkt-line. By stripping out the newline before the result gets to the caller, we will now treat the newline-only packet ("0005\n") the same as an empty packet, which in turn gets treated like a flush packet. In practice this doesn't matter, as neither empty nor newline-only packets are part of git's protocols (at least not for the line-oriented bits, and readers who are not expecting line-oriented packets will be calling packet_read directly, anyway). But even if we do decide to care about the distinction later, it is orthogonal to this patch. The right place to tighten would be to stop treating empty packets as flush packets, and this change does not make doing so any harder. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'send-pack.c')
-rw-r--r--send-pack.c6
1 files changed, 1 insertions, 5 deletions
diff --git a/send-pack.c b/send-pack.c
index bde796b1bb..8c230bf6c9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -111,10 +111,7 @@ static int receive_status(int in, struct ref *refs)
int len = packet_read_line(in, line, sizeof(line));
if (prefixcmp(line, "unpack "))
return error("did not receive remote status");
- if (strcmp(line, "unpack ok\n")) {
- char *p = line + strlen(line) - 1;
- if (*p == '\n')
- *p = '\0';
+ if (strcmp(line, "unpack ok")) {
error("unpack failed: %s", line + 7);
ret = -1;
}
@@ -131,7 +128,6 @@ static int receive_status(int in, struct ref *refs)
break;
}
- line[strlen(line)-1] = '\0';
refname = line + 3;
msg = strchr(refname, ' ');
if (msg)