Jeff King <peff@xxxxxxxx> writes: > On Tue, Mar 11, 2014 at 12:32:37PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > I think the main flag of interest is giving an fnmatch pattern to limit >> > the advertised refs. There could potentially be others, but I do not >> > know of any offhand. >> >> One thing that comes to mind is where symrefs point at, which we >> failed to add the last time around because we ran out of the >> hidden-space behind NUL. > > Yeah, good idea. I might be misremembering some complications, but we > can probably do it with: > > 1. Teach the client to send an "advertise-symrefs" flag before the ref > advertisement. > > 2. Teach the server to include symrefs in the ref advertisement; we > can invent a new syntax because we know the client has asked for > it. I was thinking more about the underlying protocol, not advertisement in particular, and I think we came to the same conclusion. The capability advertisement deserves to have its own separate packet message type, when both sides say that they understand it, so that we do not have to be limited by the pkt-line length limit. We could do one message per capability, and at the same time can lift the traditional "capability hidden after the NUL is purged every time, so we need to repeat them if we want to later change it, because that is how older clients and servers use that information" insanity, for example. -- 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