Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > PJ Hyett <pjhyett@xxxxxxxxx> wrote: > >> > >> Is there any possibility to have the server code in an upcoming > >> release account for clients running 1.6.1? > > > > I can't think off-hand of a way for the server to know what version > > the client is. There's nothing really different in the protocol > > between a 1.6.1 client and a v1.5.5-rc0~44^2 (introduction of > > include-tag) or later client. > > Hmm, I am puzzled. > > I do not know how 41fa7d2 (Teach git-fetch to exploit server side > automatic tag following, 2008-03-03), which is about the conversation > between fetch-pack and upload-pack, is relevant to the issue at hand, > which is about the conversation between send-pack and receive-pack. Oh, right, its not. I was pointing out that the last time the protocol changed in a way the server can infer something about the client, which IIRC was 41fa7d2, we still don't have a way to tell what the client is. > In send-pack receive-pack protocol, the server talks first before > listening to the client, and the .have data is in this first part of the > conversation. But as you rightly point out, that's the real problem. Since the server talks first, there's no way for the server to avoid giving out the newer ".have" lines to a buggy client, as it knows nothing at all about the client. Not even its capabilities. PJ - the short story here is, to forever work around these buggy 1.6.1 clients, you'd have to either run an old server forever, or forever run a patched server that disables the newer ".have" extension in the advertised data written by git-upload-pack. There just isn't a way to hide this from the client. Really though, I'd recommend getting your users to upgrade to a non-buggy client. Pasky has the same problem on repo.or.cz; if he doesn't have it already he will soon when he upgrades... -- Shawn. -- 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
