From: Derrick Stolee <stolee@gmail.com>
To: "Brandon Williams" <bmwill@google.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Stefan Beller <sbeller@google.com>,
Christian Hesse <mail@eworm.de>
Subject: Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Date: Thu, 26 Apr 2018 08:44:40 -0400 [thread overview]
Message-ID: <4d0bd1a2-2f51-4a11-7e31-1e1ac5213c51@gmail.com> (raw)
In-Reply-To: <20180425174300.GA49485@google.com>
On 4/25/2018 1:43 PM, Brandon Williams wrote:
> On 04/25, Ævar Arnfjörð Bjarmason wrote:
>>> * bw/protocol-v2 (2018-03-15) 35 commits
>>> (merged to 'next' on 2018-04-11 at 23ee234a2c)
>>> + remote-curl: don't request v2 when pushing
>>> + remote-curl: implement stateless-connect command
>>> + http: eliminate "# service" line when using protocol v2
>>> + http: don't always add Git-Protocol header
>>> + http: allow providing extra headers for http requests
>>> + remote-curl: store the protocol version the server responded with
>>> + remote-curl: create copy of the service name
>>> + pkt-line: add packet_buf_write_len function
>>> + transport-helper: introduce stateless-connect
>>> + transport-helper: refactor process_connect_service
>>> + transport-helper: remove name parameter
>>> + connect: don't request v2 when pushing
>>> + connect: refactor git_connect to only get the protocol version once
>>> + fetch-pack: support shallow requests
>>> + fetch-pack: perform a fetch using v2
>>> + upload-pack: introduce fetch server command
>>> + push: pass ref prefixes when pushing
>>> + fetch: pass ref prefixes when fetching
>>> + ls-remote: pass ref prefixes when requesting a remote's refs
>>> + transport: convert transport_get_remote_refs to take a list of ref prefixes
>>> + transport: convert get_refs_list to take a list of ref prefixes
>>> + connect: request remote refs using v2
>>> + ls-refs: introduce ls-refs server command
>>> + serve: introduce git-serve
>>> + test-pkt-line: introduce a packet-line test helper
>>> + protocol: introduce enum protocol_version value protocol_v2
>>> + transport: store protocol version
>>> + connect: discover protocol version outside of get_remote_heads
>>> + connect: convert get_remote_heads to use struct packet_reader
>>> + transport: use get_refs_via_connect to get refs
>>> + upload-pack: factor out processing lines
>>> + upload-pack: convert to a builtin
>>> + pkt-line: add delim packet support
>>> + pkt-line: allow peeking a packet line without consuming it
>>> + pkt-line: introduce packet_read_with_status
>>> (this branch is used by bw/server-options.)
>>>
>>> The beginning of the next-gen transfer protocol.
>>>
>>> Will cook in 'next'.
>> With a month & 10 days of no updates & this looking stable it would be
>> great to have it in master sooner than later to build on top of it in
>> the 2.18 window.
> I personally think that this series is ready to graduate to master but I
> mentioned to Junio off-list that it might be a good idea to wait until
> it has undergone a little more stress testing. We've been in the
> process of trying to get this rolled out to our internal server but due
> to a few roadblocks and people being out of the office its taken a bit
> longer than I would have liked to get it up and running. I'm hoping in
> another few days/a week I'll have some more data on live traffic. At
> that point I think I'll be more convinced that it will be safe to merge it.
>
> I may be overly cautions but I'm hoping that we can get this right
> without needing to do another protocol version bump for a very long
> time. Technically using v2 is hidden behind an "experimental" config
> flag so we should still be able to tweak it after the fact if we
> absolutely needed to, but I'd like to avoid that if necessary.
There's no testing better than production. I think if we have an
opportunity to test with realistic traffic, we should take advantage.
But I also agree that this series looks stable.
I realize it's hard to communicate both "this series is ready to merge"
and "I appreciate your caution."
Thanks,
-Stolee
next prev parent reply other threads:[~2018-04-26 12:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 8:37 What's cooking in git.git (Apr 2018, #03; Wed, 25) Junio C Hamano
2018-04-25 10:35 ` Ævar Arnfjörð Bjarmason
2018-04-25 17:43 ` Brandon Williams
2018-04-26 12:44 ` Derrick Stolee [this message]
2018-04-27 7:02 ` Johannes Schindelin
2018-04-25 12:37 ` js/rebase-recreate-merge, was " Johannes Schindelin
2018-04-25 16:21 ` Elijah Newren
2018-04-26 4:39 ` Junio C Hamano
2018-04-26 1:13 ` brian m. carlson
2018-04-26 15:26 ` Duy Nguyen
2018-04-27 7:39 ` Eric Sunshine
2018-04-30 0:03 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d0bd1a2-2f51-4a11-7e31-1e1ac5213c51@gmail.com \
--to=stolee@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mail@eworm.de \
--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.
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 NNTP newsgroup(s).