# [PATCH] pack-protocol: fix first-want separator in the examples 2 messages from 2012-05-11 to 2012-05-14. Participants: Carlos Martín Nieto, Junio C Hamano. Thread: https://gitlist.dev/t/30514 ## Carlos Martín Nieto, 2012-05-11 23:44 Subject: [PATCH] pack-protocol: fix first-want separator in the examples Message-ID: <1336779893-23636-1-git-send-email-cmn@elego.de> URL: https://gitlist.dev/e/1336779893-23636-1-git-send-email-cmn%40elego.de ``` When sending the "want" list, the capabilities list is separated from the obj-id by a SP instead of NUL as in the ref advertisement. The text is correct, but the examples wrongly show the separator as NUL. Fix the example so it uses SP. Signed-off-by: Carlos Martín Nieto --- Just after this, in the push section, it separates by NUL again. Running git-receive-pack locally looks like it's actually NUL SP, but I'm guessing that the SP comes from a printf that doesn't take being first into account, so I left it alone. Why no, I didn't just spend way too long trying to figure out why the git server wasn't reacting to my capabilites list, why do you ask? Documentation/technical/pack-protocol.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 546980c..49cdc57 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -351,7 +351,7 @@ Then the server will start sending its packfile data. A simple clone may look like this (with no 'have' lines): ---- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ side-band-64k ofs-delta\n C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n @@ -367,7 +367,7 @@ A simple clone may look like this (with no 'have' lines): An incremental update (fetch) response might look like this: ---- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ side-band-64k ofs-delta\n C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n -- 1.7.10 ``` ## Junio C Hamano, 2012-05-14 16:32 Subject: Re: [PATCH] pack-protocol: fix first-want separator in the examples Message-ID: <7vmx5aiuz1.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vmx5aiuz1.fsf%40alter.siamese.dyndns.org In-Reply-To: <1336779893-23636-1-git-send-email-cmn@elego.de> ``` Carlos Martín Nieto writes: > Just after this, in the push section, it separates by NUL > again. Running git-receive-pack locally looks like it's actually NUL > SP, but I'm guessing that the SP comes from a printf that doesn't take > being first into account, so I left it alone. That leading SP was a misguided one step in the right direction ;-) to always delimit both ends with SP, so that strstr(capabilities, " cap ") can see if capability 'cap' is advertised. So the protocol definition that says "capability-list follows NUL" is correct, but capability-list can have extra SPs on either end (or in between tokens for that matter), and what you observed has an extra SP at the beginning. It was misguided because the capability finding code has to be able to read output from older implementations that didn't try to be helpful to strstr(capabilities, " cap ") style parsers; in other words, if all the implementations advertised their capabilities that way from day one, it would have helped, but retrofitting that does not help very much. ```