From: Andy Shevchenko <email@example.com>
To: Jeff King <firstname.lastname@example.org>
Cc: "Kirill A. Shutemov" <email@example.com>,
Konstantin Ryabitsev <firstname.lastname@example.org>
Subject: Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy
Date: Tue, 31 Aug 2021 11:46:55 +0300 [thread overview]
Message-ID: <YS3sfzlkTjFXTWVh@smile.fi.intel.com> (raw)
On Tue, Aug 31, 2021 at 02:03:30AM -0400, Jeff King wrote:
> On Tue, Aug 31, 2021 at 01:42:15AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Aug 30, 2021 at 04:37:50PM -0400, Jeff King wrote:
> > > I am sympathetic that this used to work, and now doesn't. But this proxy
> > > case is affected by the problem that ae1a7eefff was solving. The root of
> > > the issue is just that "socat" in its default form is not doing the
> > > right thing. So I'd prefer not to try to make any change to Git's
> > > behavior here.
> > As a kernel developer I learned hard way that breaking user experience by
> > kernel changes considered a kernel regression, even if userspace "does it
> > wrong"™. I'm not sure what standard of care for Git users is.
> > I'm fine adjusting the proxy script and make my colleagues aware about the
> > issue, but the approach doesn't scale.
> I think we're a little less extreme there than the kernel. Like I said,
> my preference is to leave Git as-is, but if somebody feels strongly, I
> don't think it would be that hard to leave core.gitproxy untouched here.
So far the massive (annoying) Git breakage happened second time to me (*).
I would agree with you if it's rare to happen, to me it's like once per
~2 years. So, can you define what the tolerable period of time is when
I have to expect a Git breakage next time?
(*) First time it was a few years ago when out of a sudden Git started to pull
gigabytes of repositories without any need. It was annoying, but tolerable to
some extent. Current situation is not better form my user perspective.
> I agree it doesn't scale, but my suspicion is that we're talking about
> an extremely small population here. IMHO we should be considering
> deprecating git:// entirely (from Git itself, and kernel.org should
> consider turning it off). In the v2 protocol, there's no advantage to
> using it over HTTP.
So far don't you need to support current use cases?
(Here of course a philosophical question: is a driver moves a car, or the car moves the driver)
> > > But one option would be to limit it only to ssh, and not
> > > git:// proxies (we already don't do that half-duplex shutdown for raw
> > > TCP git://, for reasons discussed in that commit message).
> > I wounder if it's possible to detect the situation, warn the user that
> > gitproxy has to be fixed and retry fetching pack without closing fd.
> I don't think it can be easily distinguished from an actual network
> hangup (or proxy command failure, etc). I would much rather stop doing
> the close() entirely than add any kind of heuristic retry.
With Best Regards,
prev parent reply other threads:[~2021-08-31 8:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 16:11 Problem accessing git.kernel.org with git v2.33 plus gitproxy Kirill A. Shutemov
2021-08-30 16:35 ` Konstantin Ryabitsev
2021-08-30 17:46 ` Pratyush Yadav
2021-08-30 18:04 ` Kirill A. Shutemov
2021-08-30 18:29 ` Andy Shevchenko
2021-08-30 18:30 ` Andy Shevchenko
2021-08-30 18:16 ` Jeff King
2021-08-30 18:28 ` Kirill A. Shutemov
2021-08-30 20:37 ` Jeff King
2021-08-30 22:42 ` Kirill A. Shutemov
2021-08-31 6:03 ` Jeff King
2021-08-31 8:46 ` Andy Shevchenko [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).