{"thread":{"id":"30514","subject":"[PATCH] pack-protocol: fix first-want separator in the examples","startedAt":"2012-05-11T23:44:53Z","lastAt":"2012-05-14T16:32:50Z","messageCount":2,"participants":["Carlos Martín Nieto","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"191428","messageId":"1336779893-23636-1-git-send-email-cmn@elego.de","threadId":"30514","inReplyTo":null,"subject":"[PATCH] pack-protocol: fix first-want separator in the examples","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-05-11T23:44:53Z","receivedAt":"2012-05-11T23:44:53Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"When sending the \"want\" list, the capabilities list is separated from\nthe obj-id by a SP instead of NUL as in the ref advertisement. The\ntext is correct, but the examples wrongly show the separator as\nNUL. Fix the example so it uses SP.\n\nSigned-off-by: Carlos Martín Nieto <cmn@elego.de>\n---\n\nJust after this, in the push section, it separates by NUL\nagain. Running git-receive-pack locally looks like it's actually NUL\nSP, but I'm guessing that the SP comes from a printf that doesn't take\nbeing first into account, so I left it alone.\n\nWhy no, I didn't just spend way too long trying to figure out why the\ngit server wasn't reacting to my capabilites list, why do you ask?\n\n Documentation/technical/pack-protocol.txt |    4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\nindex 546980c..49cdc57 100644\n--- a/Documentation/technical/pack-protocol.txt\n+++ b/Documentation/technical/pack-protocol.txt\n@@ -351,7 +351,7 @@ Then the server will start sending its packfile data.\n A simple clone may look like this (with no 'have' lines):\n \n ----\n-   C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\\0multi_ack \\\n+   C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \\\n      side-band-64k ofs-delta\\n\n    C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\\n\n    C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\\n\n@@ -367,7 +367,7 @@ A simple clone may look like this (with no 'have' lines):\n An incremental update (fetch) response might look like this:\n \n ----\n-   C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\\0multi_ack \\\n+   C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \\\n      side-band-64k ofs-delta\\n\n    C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\\n\n    C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\\n\n-- \n1.7.10\n"},{"id":"191500","messageId":"7vmx5aiuz1.fsf@alter.siamese.dyndns.org","threadId":"30514","inReplyTo":"1336779893-23636-1-git-send-email-cmn@elego.de","subject":"Re: [PATCH] pack-protocol: fix first-want separator in the examples","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-14T16:32:50Z","receivedAt":"2012-05-14T16:32:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> Just after this, in the push section, it separates by NUL\n> again. Running git-receive-pack locally looks like it's actually NUL\n> SP, but I'm guessing that the SP comes from a printf that doesn't take\n> being first into account, so I left it alone.\n\nThat leading SP was a misguided one step in the right direction ;-) to\nalways delimit both ends with SP, so that strstr(capabilities, \" cap \")\ncan see if capability 'cap' is advertised.  So the protocol definition\nthat says \"capability-list follows NUL\" is correct, but capability-list\ncan have extra SPs on either end (or in between tokens for that matter),\nand what you observed has an extra SP at the beginning.\n\nIt was misguided because the capability finding code has to be able to\nread output from older implementations that didn't try to be helpful to\nstrstr(capabilities, \" cap \") style parsers; in other words, if all the\nimplementations advertised their capabilities that way from day one, it\nwould have helped, but retrofitting that does not help very much.\n"}]}