From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>,
Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config
Date: Thu, 29 Mar 2018 18:17:25 -0400 [thread overview]
Message-ID: <20180329221725.GM2939@sigill.intra.peff.net> (raw)
In-Reply-To: <20180329220257.GA209272@aiede.svl.corp.google.com>
On Thu, Mar 29, 2018 at 03:03:54PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Wed, Mar 28, 2018 at 01:33:03PM -0700, Jonathan Nieder wrote:
>
> >> When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12,
> >> 2017-12-08), it was guarded by the uploadpack.allowFilter config item
> >> to allow server operators to control when they start supporting it.
> >>
> >> That config item didn't go far enough, though: it controls whether the
> >> 'filter' capability is advertised, but if a (custom) client ignores
> >> the capability advertisement and passes a filter specification anyway,
> >> the server would handle that despite allowFilter being false.
> [...]
> > Great catch. If I understand correctly, this is an issue in the 2.17.0
> > release candidates. Is this worth delaying the release?
>
> Yes, IMHO this is a release blocker. (To put it another way, if this is
> going to delay the release, then we need to revert that patch.)
I think I'd agree on it being a release blocker. Given that your fix is
really a one-liner (3 of the lines are just changing the variable name,
which I agree with), I'd be fine with applying it on top rather than
reverting the original, even if it means delaying the release slightly.
It seems like about the same amount of risk to me.
(Sometimes it's actually _less_ risky to apply the one-liner fix,
because reverting a large feature can have unintended interactions with
other features that were built in the meantime. Looking at the original
patch, though, I doubt that is the case here, hence my "about the same
amount of risk").
-Peff
next prev parent reply other threads:[~2018-03-29 22:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 20:33 [RFC/PATCH] upload-pack: disable object filtering when disabled by config Jonathan Nieder
2018-03-28 22:12 ` Junio C Hamano
2018-03-29 13:47 ` Jeff Hostetler
2018-03-29 21:55 ` Jeff King
2018-03-29 22:03 ` Jonathan Nieder
2018-03-29 22:17 ` Jeff King [this message]
2018-03-29 22:31 ` Junio C Hamano
2018-03-30 1:45 ` 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=20180329221725.GM2939@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeffhost@microsoft.com \
--cc=jonathantanmy@google.com \
--cc=jrnieder@gmail.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).