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

From: Jeff King <peff@peff.net>
Date: Aug 31, 2021, 06:03 UTC
Message-ID: <YS3GMqz4WHUS0Cjt@coredump.intra.peff.net>
In-Reply-To: <20210830224215.hay6rjbt3vk26nk5@box>

On Tue, Aug 31, 2021 at 01:42:15AM +0300, Kirill A. Shutemov wrote:

Show 13 quoted lines

> 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.

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.

Show 6 quoted lines

> > 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.

-Peff