On Tue, 2016-05-03 at 01:33 -0400, Jeff King wrote:
> On Mon, May 02, 2016 at 02:57:43PM -0400, David Turner wrote:
>
> > On Fri, 2016-04-29 at 16:34 -0700, Stefan Beller wrote:
> >
> > > +const char *known_capabilities[] = {
> > > + "multi_ack",
> > > + "thin-pack",
> > > + "side-band",
> > > + "side-band-64k",
> > > + "ofs-delta",
> > > + "shallow",
> > > + "no-progress",
> > > + "include-tag",
> > > + "multi_ack_detailed",
> > > + "allow-tip-sha1-in-want",
> > > + "allow-reachable-sha1-in-want",
> > > + "no-done",
> > > +};
> >
> > I wonder if it is possible to not repeat the list from upload
> > -pack.c?
> > It seems unfortunate to have to add the same string in two places
> > whenever you add a capability.
>
> I think that in general, we'd stop adding capabilities to v1. If you
> have a client which speaks the new capability, then it should also be
> speaking the new protocol. That's not strictly true if other non
> -git.git
> implementations want to learn capability X but not protocol v2, but I
> think in practice it's not an unreasonable world view.
>
> I guess there may be a grey area for a while, though, where even
> v2-capable clients don't end up speaking it, because they don't yet
> know
> that a particular server can handle it. So any capabilities added in
> that grey area may want to go to both v1 and v2.
OK, but then there should be one list per protocol version rather than
two copies of the same list.
--
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