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 Tan <jonathantanmy@google.com>,
	git@vger.kernel.org, steadmon@google.com
Subject: Re: [PATCH 2/8] tests: always test fetch of unreachable with v0
Date: Fri, 22 Feb 2019 12:47:42 -0800	[thread overview]
Message-ID: <xmqqimxbpn2p.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190221134954.GC21406@sigill.intra.peff.net> (Jeff King's message of "Thu, 21 Feb 2019 08:49:54 -0500")

Jeff King <peff@peff.net> writes:

> On Thu, Feb 14, 2019 at 11:58:25AM -0800, Jonathan Tan wrote:
>
>> > On Tue, Feb 05, 2019 at 04:21:16PM -0800, Jonathan Tan wrote:
>> > 
>> > > Some tests check that fetching an unreachable object fails, but protocol
>> > > v2 allows such fetches. Unset GIT_TEST_PROTOCOL_VERSION so that these
>> > > tests are always run using protocol v0.
>> > 
>> > I think this is reasonable, but just musing on a few things:
>> > 
>> >   1. Are we sure going forward that we want to retain this behavior? I
>> >      feel like we discussed this on the list recently with no real
>> >      conclusion, but I'm having trouble digging it up in the archive.
>> 
>> One such discussion is here:
>> https://public-inbox.org/git/20181214101232.GC13465@sigill.intra.peff.net/
>
> Thanks, that was what I was thinking of, though there doesn't seem to
> have been much discussion in response. :)
>
>> >   2. If it does change, is there any way we could automatically find
>> >      spots like this that would then need to be undone? I cannot think
>> >      of a good solution, and I don't think it's a show-stopper not to
>> >      have one, but I thought I'd put it forward as a concept.
>> 
>> We can do so now either by "blaming" one and finding the originating
>> commit, or by searching for "support fetching unadvertised objects" (I
>> used the same comment everywhere in the commit [1] so that people can do
>> this), but I don't know how to enforce this for future work. (We can add
>> a special variable, but I think it's unnecessary and we can't enforce
>> that people use that new special variable instead of
>> GIT_TEST_PROTOCOL_VERSION anyway.)
>
> Yeah, I think we can find them once we know they need fixing. I was more
> wondering whether we would remember to do so. I.e., is there a way the
> test suite could remind us when our assumptions change. I can't think of
> an easy way to do so, though.

Perhaps looking it a different way may help.  Instead of saying "v2
will not protect unreachable objects, so this test must be run with
v0", think of it like "Git ought to protect unreachable objects, so
test with different versions of protocols to make sure all satisfy
the requirement---for now, v2 is known to be broken, so write it
with test_expect_failure".  IOW, have one test for each version,
some of them may document a known breakage.



  reply	other threads:[~2019-02-22 20:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06  0:21 [PATCH 0/8] Resend of GIT_TEST_PROTOCOL_VERSION patches Jonathan Tan
2019-02-06  0:21 ` [PATCH 1/8] tests: define GIT_TEST_PROTOCOL_VERSION Jonathan Tan
2019-02-06 21:58   ` Ævar Arnfjörð Bjarmason
2019-02-07  0:01     ` Jonathan Tan
2019-02-11 20:20   ` Jeff King
2019-02-06  0:21 ` [PATCH 2/8] tests: always test fetch of unreachable with v0 Jonathan Tan
2019-02-11 20:30   ` Jeff King
2019-02-14 19:58     ` Jonathan Tan
2019-02-21 13:49       ` Jeff King
2019-02-22 20:47         ` Junio C Hamano [this message]
2019-02-23 13:25           ` Jeff King
2019-02-06  0:21 ` [PATCH 3/8] t5503: fix overspecification of trace expectation Jonathan Tan
2019-02-06  0:21 ` [PATCH 4/8] t5512: compensate for v0 only sending HEAD symrefs Jonathan Tan
2019-02-06  0:21 ` [PATCH 5/8] t5700: only run with protocol version 1 Jonathan Tan
2019-02-06  0:21 ` [PATCH 6/8] tests: fix protocol version for overspecifications Jonathan Tan
2019-02-06  0:21 ` [PATCH 7/8] t5552: compensate for v2 filtering ref adv Jonathan Tan
2019-02-06  0:21 ` [PATCH 8/8] remote-curl: in v2, fill credentials if needed Jonathan Tan
2019-02-06 21:29   ` Jeff King
2019-02-11 19:20     ` Jonathan Tan
2019-02-11 20:38       ` Jeff King
2019-02-06 21:34 ` [PATCH 0/8] Resend of GIT_TEST_PROTOCOL_VERSION patches Jeff King
2019-02-06 21:52   ` Ævar Arnfjörð Bjarmason
2019-02-06 22:10     ` Jeff King
2019-02-06 22:20       ` Ævar Arnfjörð Bjarmason
2019-02-06 23:08         ` Jeff King
2019-02-07 10:49           ` Ævar Arnfjörð Bjarmason

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=xmqqimxbpn2p.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=peff@peff.net \
    --cc=steadmon@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).