From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: avarab@gmail.com, git@vger.kernel.org
Subject: Re: [WIP 0/8] Trying to revive GIT_TEST_PROTOCOL_VERSION
Date: Thu, 17 Jan 2019 13:18:39 -0800 [thread overview]
Message-ID: <xmqqfttrm18w.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190117183727.260298-1-jonathantanmy@google.com> (Jonathan Tan's message of "Thu, 17 Jan 2019 10:37:27 -0800")
Jonathan Tan <jonathantanmy@google.com> writes:
>> I'm happy to have you pick that up as you've done here, especially since
>> you're actually working on v2 and I'm not, so you can more easily know
>> what it conflicts with etc. I just wanted to have it in one way or
>> another, i.e. be able to deploy v2 and assert that "next + custom
>> patches" doesn't break something for v2.
>>
>> I think [CC: Junio] that we shouldn't be concerned about an addition of
>> GIT_TEST_PROTOCOL_VERSION patches in any form breaking the test suite
>> under GIT_TEST_PROTOCOL_VERSION=2, and just be concerned about the
>> default GIT_TEST_PROTOCOL_VERSION= case. I.e. if we have v2 patches
>> in-flight that break things no big deal, we can always circle back and
>> fix those things or annotate the tests.
>
> That sounds good to me. My main concern is that this will end up being
> dead code (if we have too many tests that fail with
> GIT_TEST_PROTOCOL_VERSION=2 and no one bothers with it anymore), but I
> don't think that will happen - in this patch set, I have eliminated a
> lot of false failures and strove to give reasons for the
> GIT_TEST_PROTOCOL_VERSION= annotations, and I think there's interest
> (well, at least from me) in investigating the remaining apparent bugs.
Yup, sounds good to me, too.
prev parent reply other threads:[~2019-01-17 21:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 22:42 [WIP 0/8] Trying to revive GIT_TEST_PROTOCOL_VERSION Jonathan Tan
2019-01-16 22:42 ` [WIP 1/8] tests: define GIT_TEST_PROTOCOL_VERSION Jonathan Tan
2019-01-16 22:42 ` [WIP 2/8] tests: always test fetch of unreachable with v0 Jonathan Tan
2019-01-16 22:42 ` [WIP 3/8] t5503: fix overspecification of trace expectation Jonathan Tan
2019-01-16 22:42 ` [WIP 4/8] t5512: compensate for v0 only sending HEAD symrefs Jonathan Tan
2019-01-16 22:42 ` [WIP 5/8] t5700: only run with protocol version 1 Jonathan Tan
2019-01-16 22:42 ` [WIP 6/8] tests: fix protocol version for overspecifications Jonathan Tan
2019-01-16 22:42 ` [WIP 7/8] t5552: compensate for v2 filtering ref adv Jonathan Tan
2019-01-16 22:42 ` [WIP 8/8] remote-curl: in v2, fill credentials if needed Jonathan Tan
2019-01-17 9:31 ` [WIP 0/8] Trying to revive GIT_TEST_PROTOCOL_VERSION Ævar Arnfjörð Bjarmason
2019-01-17 18:37 ` Jonathan Tan
2019-01-17 21:18 ` Junio C Hamano [this message]
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=xmqqfttrm18w.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.