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