Carlos Martín Nieto <cmn@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html