Re: [RFC] multi_ack protocol v2

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 27, 2005, 10:47 UTC
Message-ID: <Pine.LNX.4.63.0510271227490.2724@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20051027141619.0e8029f2.vsu@altlinux.ru>

Hi,

On Thu, 27 Oct 2005, Sergey Vlasov wrote:

Show 6 quoted lines

> Actually, there is another way to pass some data from the server
> which would be ignored by older clients - at the first stage,
> when upload-pack sends the list of refs to the client:
> 
> 	packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname, '\0',
> 		     server_capabilities);

That exploits that packet_write() uses vnsprintf() to find out the length, not strlen(). Sweet.

get_remote_heads() would need to store the server_capabilities, maybe with a function "server_supports(const char *extension_string)"

Actually, I like that even more than Junio's proposal. I was thinking hard about how to enhance get_ack() to understand -- and most importantly to return -- the capabilities. I could not think of an elegant way.

So, unless people complain, I'll go with that approach.

> This looks cleaner (no NUL bytes in the protocol), but does not
> allow to replace the "want" stage with something entirely
> different (if we ever want to do that).

Also it feels wrong that a client should ask for capabilities, where it does not yet know if the server supports them.

Ciao, Dscho