git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC/PATCH 0/3] protocol v2
Date: Mon, 23 Feb 2015 21:40:43 -0800	[thread overview]
Message-ID: <CAGZ79kYhUyRyvf6ou1QWM1j1L1X2YwCbZaNuVp6jJMyUcpwb+A@mail.gmail.com> (raw)
In-Reply-To: <CACsJy8BSf2h_xD-Q1tudAg_xCzffRQM+7xzUgprONxD7vM5RYw@mail.gmail.com>

On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Tue, Feb 24, 2015 at 10:12 AM, Stefan Beller <sbeller@google.com> wrote:
>> One of the biggest problems of a new protocol would be deployment
>> as the users probably would not care too deeply. It should just
>> work in the sense that the user should not even sense that the
>> protocol changed.
>
> Agreed.
>
>> To do so we need to make sure the protocol
>> is backwards compatible and works if an old client talks to
>> a new server as well as the other way round.
>
> It's very hard to keep backward compatibility if you want to stop the
> initial ref adverstisement, costly when there are lots of refs. But we
> can let both protocols run in parallel, with the old one advertise the
> presence of the new one.

That's what I actually meant, to have different versions out there,
but maybe having the version as of now as the least common denominator
such that it always works (albeit inefficient for many refs).

> Then the client could switch to new protocol
> gradually. This way new protocol could forget about backward
> compatibility. See
>
> http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325
> --
> Duy

> I would add that upload-pack also advertises about the availability of
> upload-pack2 and the client may set the remote.*.useUploadPack2 to
> either yes or auto so next time upload-pack2 will be used.

I had a similar thought, though I would not just restrict it to v2
this time, but
I'd aim to make it possible to plug whatever protocol you want to.
(Comparable to the SSL or ssh, it will always work, but as a proficient user
you can spend lot's of time tweaking what you actually want, looking
at tradeoffs
of efficiency, security, convenience).

  reply	other threads:[~2015-02-24  5:40 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24  3:12 [RFC/PATCH 0/3] protocol v2 Stefan Beller
2015-02-24  3:12 ` [PATCH 1/3] Document protocol capabilities extension Stefan Beller
2015-02-24  3:12 ` [PATCH 2/3] receive-pack: add advertisement of different protocol options Stefan Beller
2015-02-24  3:12 ` [PATCH 3/3] receive-pack: enable protocol v2 Stefan Beller
2015-02-24  4:02 ` [RFC/PATCH 0/3] " Duy Nguyen
2015-02-24  5:40   ` Stefan Beller [this message]
2015-02-24  6:15   ` Junio C Hamano
2015-02-24 23:37     ` Stefan Beller
2015-02-25 12:44       ` Duy Nguyen
2015-02-25 18:04         ` Junio C Hamano
2015-02-26  7:31           ` Stefan Beller
2015-02-26 10:15             ` Duy Nguyen
2015-02-26 20:08               ` Stefan Beller
     [not found]                 ` <CACsJy8DOS_999ZgW7TqsH-dkrUFpjZf0TFQeFUt9s0bNhHY0Bw@mail.gmail.com>
2015-02-27 22:20                   ` Stefan Beller
2015-02-26 20:13               ` Junio C Hamano
2015-02-27  1:26                 ` Stefan Beller
2015-02-27  2:15                   ` Stefan Beller
2015-02-27 23:05                 ` Junio C Hamano
2015-02-27 23:44                   ` Stefan Beller
2015-02-28  0:33                     ` Junio C Hamano
2015-02-28  0:46                       ` Stefan Beller
2015-02-28  1:01                         ` [RFC/PATCH 0/5] protocol v2 for upload-pack Stefan Beller
2015-02-28  1:01                           ` [RFC/PATCH 1/5] upload-pack: only accept capabilities on the first "want" line Stefan Beller
2015-02-28  1:01                           ` [RFC/PATCH 2/5] upload-pack: support out of band client capability requests Stefan Beller
2015-02-28  7:47                             ` Kyle J. McKay
2015-02-28 11:22                               ` Duy Nguyen
2015-02-28 22:36                                 ` Kyle J. McKay
2015-03-01  0:11                                   ` Duy Nguyen
2015-02-28 11:36                             ` Duy Nguyen
2015-02-28  1:01                           ` [RFC/PATCH 3/5] connect.c: connect to a remote service with some flags Stefan Beller
2015-02-28 11:11                             ` Torsten Bögershausen
2015-03-01  3:22                             ` Junio C Hamano
2015-02-28  1:01                           ` [RFC/PATCH 4/5] daemon.c: accept extra service arguments Stefan Beller
2015-03-01  3:39                             ` Junio C Hamano
2015-02-28  1:01                           ` [RFC/PATCH 5/5] WIP/Document the http protocol change Stefan Beller
2015-02-28 12:26                             ` Duy Nguyen
2015-03-01  9:11                           ` [RFC/PATCH 0/5] protocol v2 for upload-pack Johannes Sixt
2015-03-02  2:58                             ` Junio C Hamano
2015-03-02  3:47                         ` [RFC/PATCH 0/3] protocol v2 Junio C Hamano
2015-03-02  9:21                           ` Duy Nguyen
2015-03-02  9:24                             ` Duy Nguyen
2015-03-03 10:33                             ` Duy Nguyen
2015-03-03 17:13                               ` Junio C Hamano
2015-03-03 19:47                                 ` Junio C Hamano
2015-03-04  1:54                                 ` Duy Nguyen
2015-03-04  4:27                                   ` Shawn Pearce
2015-03-04 12:05                                     ` Duy Nguyen
2015-03-04 19:10                                       ` Shawn Pearce
2015-03-05  1:03                                         ` Stefan Beller
2015-03-05 16:03                                           ` Stefan Beller
2015-03-24 17:42                                 ` Stefan Beller
2015-03-24 18:00                                   ` Junio C Hamano
2015-03-06 23:38                             ` [PATCH] protocol upload-pack-v2 Stefan Beller
2015-03-06 23:40                               ` Stefan Beller
2015-03-06 23:55                               ` Duy Nguyen
2015-03-07  0:00                               ` Duy Nguyen
2015-03-07  0:28                               ` Junio C Hamano
2015-03-07  4:28                                 ` Stefan Beller
2015-03-07  5:21                                   ` Duy Nguyen
2015-03-08 20:36                                   ` Junio C Hamano
2015-03-31 19:58                                     ` Junio C Hamano
2015-04-02 12:37                                       ` Duy Nguyen
2015-04-02 14:45                                         ` Junio C Hamano
2015-04-02 22:18                                       ` Martin Fick
2015-04-02 22:58                                         ` Junio C Hamano
2015-04-02 23:00                                         ` Stefan Beller
2015-04-02 23:14                                           ` Stefan Beller
2015-03-10  1:38                               ` Duy Nguyen
2015-03-10 19:36                                 ` Kyle J. McKay
2015-02-28  0:07                   ` [RFC/PATCH 0/3] protocol v2 Duy Nguyen
2015-02-28  0:26                     ` Junio C Hamano
2015-03-01  8:41     ` Junio C Hamano
2015-03-01 11:32       ` Duy Nguyen
2015-03-01 19:56         ` Stefan Beller
2015-03-02  1:05           ` David Lang
2015-03-01 23:06         ` Junio C Hamano
2015-03-02  1:09           ` David Lang
2015-03-02  3:10             ` Junio C Hamano
2015-03-01 23:06       ` Philip Oakley
2015-03-02  9:32         ` Duy Nguyen

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=CAGZ79kYhUyRyvf6ou1QWM1j1L1X2YwCbZaNuVp6jJMyUcpwb+A@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.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).