git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH/RFC] config: default to protocol v2
Date: Wed, 08 Jul 2020 08:42:46 -0700	[thread overview]
Message-ID: <xmqq7dve2etl.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200708045008.GC2303891@coredump.intra.peff.net> (Jeff King's message of "Wed, 8 Jul 2020 00:50:08 -0400")

Jeff King <peff@peff.net> writes:

>> Mostly sending this to get the discussion started about what changes
>> we want before flipping the default.
>
> I can't actually think of any changes we'd want to make. AFAIK aside
> from the negotiation problem, v2 is good to go. When we flipped it off
> by default for 2.27 out of caution, I had hoped we would flip it back on
> for the 2.28 cycle to get more exposure.

If there were any changes we already can think of before going
public with v2 at this moment, it makes it definitely way too late
to propose making it the default again.  I do not think of any
changes either, so I'd say it is a good sign ;-) 

> And that has been the only bug people have reported for 2.26. That
> implies to me that:
>
>   - we won't get significantly more information by leaving v2-as-default
>     in "next" or even "master" before it actually hits a release
>
>   - there probably aren't other major problems lurking, given that
>     people clearly upgraded to 2.26, found the negotiation problem, but
>     never reported any other issues

I've already said elsewhere that it is way too late to propose this
flipping back the default for this cycle but it was mainly out of
principle.  I do agree with you and Jonathan that we won't see any
further breakages in the v2 code until we expose more users to it by
making it the default in a released version.

I am afraid that "there probably aren't other" may be overly
optimistic, as the bug in 2.26 crippled the negotiation logic and
forced it to punt, which was so severe that it would have hidden any
other bugs in the negotiation logic.  If there is another bug in v2
negotiation logic that makes the sender to omit objects that should
be sent, it would not have been observed in 2.26 because the effect
of the more severe bug was to cripple the negotiation logic itself
and to make it punt, sending more objects all the way down the
history.  Now, with that larger bug fixed post 2.26, we can start to
see if there are other bugs hidden by it.

In any case, we've learned in 2.26 that it is unlikely that such
bugs would be uncovered until v2 is made the default again in a
released version to be used by more users.

So, let's flip the default in -rc0; we can revert if we see
something funny in 2.28.1 in the worst case.

Thanks.

  reply	other threads:[~2020-07-08 15:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-07  5:38 [PATCH/RFC] config: default to protocol v2 Jonathan Nieder
2020-07-08  4:50 ` Jeff King
2020-07-08 15:42   ` Junio C Hamano [this message]
2020-07-09 23:00     ` 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=xmqq7dve2etl.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    /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).