From: David Turner <dturner@twopensource.com>
To: Jeff King <peff@peff.net>
Cc: Stefan Beller <sbeller@google.com>, git@vger.kernel.org
Subject: Re: [PATCH 06/14] remote.h: add get_remote_capabilities, request_capabilities
Date: Tue, 03 May 2016 17:21:26 -0400 [thread overview]
Message-ID: <1462310486.4123.81.camel@twopensource.com> (raw)
In-Reply-To: <20160503053337.GA17986@sigill.intra.peff.net>
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.
next prev parent reply other threads:[~2016-05-03 21:21 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 23:34 [WIP PATCH 00/14] Protocol v2 patches Stefan Beller
2016-04-29 23:34 ` [PATCH 01/14] upload-pack: make client capability parsing code a separate function Stefan Beller
2016-04-29 23:34 ` [PATCH 02/14] upload-pack.c: Refactor capability advertising Stefan Beller
2016-04-30 1:04 ` David Turner
2016-05-04 20:05 ` Junio C Hamano
2016-04-29 23:34 ` [PATCH 03/14] upload-pack-2: Implement the version 2 of upload-pack Stefan Beller
2016-05-02 17:43 ` David Turner
2016-05-02 17:51 ` Stefan Beller
2016-05-02 18:56 ` David Turner
2016-05-03 0:31 ` Duy Nguyen
2016-05-04 20:11 ` Junio C Hamano
2016-04-29 23:34 ` [PATCH 04/14] connect: rewrite feature parsing to work on string_list Stefan Beller
2016-05-02 18:18 ` David Turner
2016-05-02 18:46 ` Stefan Beller
2016-05-04 20:13 ` Junio C Hamano
2016-05-17 22:23 ` David Turner
2016-04-29 23:34 ` [PATCH 05/14] transport: add infrastructure to support a protocol version number Stefan Beller
2016-04-29 23:34 ` [PATCH 06/14] remote.h: add get_remote_capabilities, request_capabilities Stefan Beller
2016-05-02 18:57 ` David Turner
2016-05-03 5:33 ` Jeff King
2016-05-03 21:21 ` David Turner [this message]
2016-05-04 16:44 ` Stefan Beller
2016-04-29 23:34 ` [PATCH 07/14] fetch-pack: move capability selection out of do_fetch_pack Stefan Beller
2016-04-29 23:34 ` [PATCH 08/14] fetch-pack: factor out get_selected_capabilities_list Stefan Beller
2016-05-02 19:09 ` David Turner
2016-04-29 23:34 ` [PATCH 09/14] fetch-pack: Add negotiate_capabilities Stefan Beller
2016-04-29 23:34 ` [PATCH 10/14] do_fetch_pack: select capabilities for transport version 1 only Stefan Beller
2016-04-29 23:34 ` [PATCH 11/14] builtin/fetch-pack: add argument for transport version Stefan Beller
2016-04-29 23:34 ` [PATCH 12/14] Add test for fetch-pack Stefan Beller
2016-05-02 19:45 ` David Turner
2016-04-29 23:34 ` [PATCH 13/14] WIP add test for git pull Stefan Beller
2016-04-29 23:34 ` [PATCH 14/14] WIP test git fetch Stefan Beller
2016-05-02 20:41 ` [WIP PATCH 00/14] Protocol v2 patches David Turner
2016-05-02 20:43 ` Stefan Beller
2016-05-24 22:46 ` David Turner
2016-05-24 23:03 ` Duy Nguyen
2016-05-25 16:45 ` David Turner
2016-05-25 16:23 ` Junio C Hamano
2016-05-25 19:31 ` David Turner
2016-05-25 21:29 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1462310486.4123.81.camel@twopensource.com \
--to=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).