[PATCH] pack-protocol: fix first-want separator in the examples

[PATCH] pack-protocol: fix first-want separator in the examples

[Carlos Martín Nieto]

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 <cmn@elego.de>
---

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

Re: [PATCH] pack-protocol: fix first-want separator in the examples

[Junio C Hamano]

Carlos Martín Nieto <cmn@elego.de> 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.