Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy

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:

quoted

On Mon, Aug 30, 2021 at 04:37:50PM -0400, Jeff King wrote:

quoted

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)

quoted

quoted

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[1].

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,
Andy Shevchenko