git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, steadmon@google.com
Subject: Re: [PATCH 2/8] tests: always test fetch of unreachable with v0
Date: Thu, 21 Feb 2019 08:49:54 -0500	[thread overview]
Message-ID: <20190221134954.GC21406@sigill.intra.peff.net> (raw)
In-Reply-To: <20190214195825.125751-1-jonathantanmy@google.com>

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.

-Peff

  reply	other threads:[~2019-02-21 13:49 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 [this message]
2019-02-22 20:47         ` Junio C Hamano
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=20190221134954.GC21406@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --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).