Re: [PATCH v3 0/8] Hiding refs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]