{"thread":{"id":"56407","subject":"Problem accessing git.kernel.org with git v2.33 plus gitproxy","startedAt":"2021-08-30T16:11:55Z","lastAt":"2021-08-31T08:47:02Z","messageCount":12,"participants":["Kirill A. Shutemov","Konstantin Ryabitsev","Pratyush Yadav","Jeff King","Andy Shevchenko"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"434114","messageId":"20210830161149.xggfosjthnjxcoxp@box.shutemov.name","threadId":"56407","inReplyTo":null,"subject":"Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Kirill A. Shutemov","fromEmail":"kirill@shutemov.name","sentAt":"2021-08-30T16:11:49Z","receivedAt":"2021-08-30T16:11:55Z","isPatch":false,"sender":{"key":"kirill@shutemov.name","avatar":"https://avatars.githubusercontent.com/u/588661?v=4"},"body":"Hi folks,\n\nI've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\nfails with an error:\n\n        fetch-pack: unexpected disconnect while reading sideband packet\n\nIt only happens when I access git.kernel.org over git:// (github over\ngit:// works fine) and if there's a gitproxy configured.\n\nFor test I used a dummy gitproxy:\n\n        #!/bin/sh -efu\n        socat - \"TCP:$1:$2\"\n\nIt is enough to trigger the issue.\n\nI'm not sure if it's kernel.org problem or git problem.\n\nHas anybody else stepped on the issue? Any clues?\n\n-- \n Kirill A. Shutemov\n"},{"id":"434115","messageId":"20210830163510.4rhfeim7ceqbtti7@nitro.local","threadId":"56407","inReplyTo":"20210830161149.xggfosjthnjxcoxp@box.shutemov.name","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-08-30T16:35:10Z","receivedAt":"2021-08-30T16:35:14Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Mon, Aug 30, 2021 at 07:11:49PM +0300, Kirill A. Shutemov wrote:\n> I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> fails with an error:\n> \n>         fetch-pack: unexpected disconnect while reading sideband packet\n> \n> It only happens when I access git.kernel.org over git:// (github over\n> git:// works fine) and if there's a gitproxy configured.\n> \n> For test I used a dummy gitproxy:\n> \n>         #!/bin/sh -efu\n>         socat - \"TCP:$1:$2\"\n> \n> It is enough to trigger the issue.\n> \n> I'm not sure if it's kernel.org problem or git problem.\n\nFor the record, the git.kernel.org server-side version is 2.31.1 and it is\ninvoked via the usual xinetd straight to git-daemon with the following flags:\n\nserver_args = --interpolated-path=/var/lib/git/%H%D --init-timeout=10 --timeout=600 --export-all --syslog --inetd --verbose\n\n-K\n"},{"id":"434132","messageId":"20210830174658.zd7r6kx7s7lxlihg@yadavpratyush.com","threadId":"56407","inReplyTo":"20210830161149.xggfosjthnjxcoxp@box.shutemov.name","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2021-08-30T17:46:58Z","receivedAt":"2021-08-30T17:47:05Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 30/08/21 07:11PM, Kirill A. Shutemov wrote:\n> Hi folks,\n> \n> I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> fails with an error:\n> \n>         fetch-pack: unexpected disconnect while reading sideband packet\n> \n> It only happens when I access git.kernel.org over git:// (github over\n> git:// works fine) and if there's a gitproxy configured.\n> \n> For test I used a dummy gitproxy:\n> \n>         #!/bin/sh -efu\n>         socat - \"TCP:$1:$2\"\n> \n> It is enough to trigger the issue.\n> \n> I'm not sure if it's kernel.org problem or git problem.\n> \n> Has anybody else stepped on the issue? Any clues?\n\nI can reproduce it on my computer at work, which needs to sit behind a \nproxy. Not too sure what is causing it though.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"434136","messageId":"20210830180433.5rqqh7zsakbrfmrp@box","threadId":"56407","inReplyTo":"20210830161149.xggfosjthnjxcoxp@box.shutemov.name","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Kirill A. Shutemov","fromEmail":"kirill@shutemov.name","sentAt":"2021-08-30T18:04:33Z","receivedAt":"2021-08-30T18:04:38Z","isPatch":false,"sender":{"key":"kirill@shutemov.name","avatar":"https://avatars.githubusercontent.com/u/588661?v=4"},"body":"On Mon, Aug 30, 2021 at 07:11:50PM +0300, Kirill A. Shutemov wrote:\n> Hi folks,\n> \n> I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> fails with an error:\n> \n>         fetch-pack: unexpected disconnect while reading sideband packet\n> \n> It only happens when I access git.kernel.org over git:// (github over\n> git:// works fine) and if there's a gitproxy configured.\n> \n> For test I used a dummy gitproxy:\n> \n>         #!/bin/sh -efu\n>         socat - \"TCP:$1:$2\"\n> \n> It is enough to trigger the issue.\n> \n> I'm not sure if it's kernel.org problem or git problem.\n> \n> Has anybody else stepped on the issue? Any clues?\n\nI've bisected the issue to commit\n\n\tae1a7eefffe6 (\"fetch-pack: signal v2 server that we are done making requests\")\n\n-- \n Kirill A. Shutemov\n"},{"id":"434139","messageId":"YS0gZNRqz72hs/a5@coredump.intra.peff.net","threadId":"56407","inReplyTo":"20210830161149.xggfosjthnjxcoxp@box.shutemov.name","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-30T18:16:04Z","receivedAt":"2021-08-30T18:16:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 30, 2021 at 07:11:49PM +0300, Kirill A. Shutemov wrote:\n\n> I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> fails with an error:\n> \n>         fetch-pack: unexpected disconnect while reading sideband packet\n> \n> It only happens when I access git.kernel.org over git:// (github over\n> git:// works fine) and if there's a gitproxy configured.\n> \n> For test I used a dummy gitproxy:\n> \n>         #!/bin/sh -efu\n>         socat - \"TCP:$1:$2\"\n> \n> It is enough to trigger the issue.\n> \n> I'm not sure if it's kernel.org problem or git problem.\n> \n> Has anybody else stepped on the issue? Any clues?\n\nI can't reproduce the problem here, using core.gitproxy with a script\nidentical to what you showed above. I tried both cloning, and fetching\nvia both git-fetch and git-fetch-pack.\n\nCan you show us a more complete example? What does the command that\nfails look like? What's the repo state before you run it? At what part\nof the conversation does it fail (before a pack is sent, during, or\nafter)?\n\nIf you can reproduce it at will and it fails on 2.33 but not earlier,\nthen bisecting might be helpful.\n\n-Peff\n"},{"id":"434143","messageId":"20210830182845.pnv7ywnc364jnblt@box","threadId":"56407","inReplyTo":"YS0gZNRqz72hs/a5@coredump.intra.peff.net","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Kirill A. Shutemov","fromEmail":"kirill@shutemov.name","sentAt":"2021-08-30T18:28:45Z","receivedAt":"2021-08-30T18:28:50Z","isPatch":false,"sender":{"key":"kirill@shutemov.name","avatar":"https://avatars.githubusercontent.com/u/588661?v=4"},"body":"On Mon, Aug 30, 2021 at 02:16:04PM -0400, Jeff King wrote:\n> On Mon, Aug 30, 2021 at 07:11:49PM +0300, Kirill A. Shutemov wrote:\n> \n> > I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> > fails with an error:\n> > \n> >         fetch-pack: unexpected disconnect while reading sideband packet\n> > \n> > It only happens when I access git.kernel.org over git:// (github over\n> > git:// works fine) and if there's a gitproxy configured.\n> > \n> > For test I used a dummy gitproxy:\n> > \n> >         #!/bin/sh -efu\n> >         socat - \"TCP:$1:$2\"\n> > \n> > It is enough to trigger the issue.\n> > \n> > I'm not sure if it's kernel.org problem or git problem.\n> > \n> > Has anybody else stepped on the issue? Any clues?\n> \n> I can't reproduce the problem here, using core.gitproxy with a script\n> identical to what you showed above. I tried both cloning, and fetching\n> via both git-fetch and git-fetch-pack.\n\nCould you try with a kernel repo?\n\ngit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\n\nI found that not all repos on kernel.org trigger the issue.\n\n> Can you show us a more complete example? What does the command that\n> fails look like? What's the repo state before you run it? At what part\n> of the conversation does it fail (before a pack is sent, during, or\n> after)?\n\nThe last I see sent to the server is \"packfile\". It is consistent with the\nbisected commit. Removing close() in do_fetch_pack_v2() helps.\n\n> If you can reproduce it at will and it fails on 2.33 but not earlier,\n> then bisecting might be helpful.\n\nI did. See my other mail.\n\n-- \n Kirill A. Shutemov\n"},{"id":"434144","messageId":"YS0jopxToBW0g1Rm@smile.fi.intel.com","threadId":"56407","inReplyTo":"20210830180433.5rqqh7zsakbrfmrp@box","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Andy Shevchenko","fromEmail":"andriy.shevchenko@linux.intel.com","sentAt":"2021-08-30T18:29:54Z","receivedAt":"2021-08-30T18:30:01Z","isPatch":false,"sender":{"key":"andriy.shevchenko@linux.intel.com","avatar":"https://gravatar.com/avatar/507bf7f59fddb7004f6bf72b211f6216082913376b9d961221004ab9481d97ca?d=mp&s=160"},"body":"On Mon, Aug 30, 2021 at 09:04:33PM +0300, Kirill A. Shutemov wrote:\n> On Mon, Aug 30, 2021 at 07:11:50PM +0300, Kirill A. Shutemov wrote:\n> > Hi folks,\n> > \n> > I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> > fails with an error:\n> > \n> >         fetch-pack: unexpected disconnect while reading sideband packet\n> > \n> > It only happens when I access git.kernel.org over git:// (github over\n> > git:// works fine) and if there's a gitproxy configured.\n> > \n> > For test I used a dummy gitproxy:\n> > \n> >         #!/bin/sh -efu\n> >         socat - \"TCP:$1:$2\"\n> > \n> > It is enough to trigger the issue.\n> > \n> > I'm not sure if it's kernel.org problem or git problem.\n> > \n> > Has anybody else stepped on the issue? Any clues?\n> \n> I've bisected the issue to commit\n> \n> \tae1a7eefffe6 (\"fetch-pack: signal v2 server that we are done making requests\")\n\nThanks, Kirill!\n\nAre you going to report it to the Git community?\n\n-- \nWith Best Regards,\nAndy Shevchenko\n\n\n"},{"id":"434145","messageId":"YS0jzwsaRFaJnfo6@smile.fi.intel.com","threadId":"56407","inReplyTo":"YS0jopxToBW0g1Rm@smile.fi.intel.com","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Andy Shevchenko","fromEmail":"andriy.shevchenko@linux.intel.com","sentAt":"2021-08-30T18:30:39Z","receivedAt":"2021-08-30T18:30:46Z","isPatch":false,"sender":{"key":"andriy.shevchenko@linux.intel.com","avatar":"https://gravatar.com/avatar/507bf7f59fddb7004f6bf72b211f6216082913376b9d961221004ab9481d97ca?d=mp&s=160"},"body":"On Mon, Aug 30, 2021 at 09:29:54PM +0300, Andy Shevchenko wrote:\n> On Mon, Aug 30, 2021 at 09:04:33PM +0300, Kirill A. Shutemov wrote:\n> > On Mon, Aug 30, 2021 at 07:11:50PM +0300, Kirill A. Shutemov wrote:\n> > > Hi folks,\n> > > \n> > > I've stepped on a problem after upgrading git to v2.33.0. git fetch-pack\n> > > fails with an error:\n> > > \n> > >         fetch-pack: unexpected disconnect while reading sideband packet\n> > > \n> > > It only happens when I access git.kernel.org over git:// (github over\n> > > git:// works fine) and if there's a gitproxy configured.\n> > > \n> > > For test I used a dummy gitproxy:\n> > > \n> > >         #!/bin/sh -efu\n> > >         socat - \"TCP:$1:$2\"\n> > > \n> > > It is enough to trigger the issue.\n> > > \n> > > I'm not sure if it's kernel.org problem or git problem.\n> > > \n> > > Has anybody else stepped on the issue? Any clues?\n> > \n> > I've bisected the issue to commit\n> > \n> > \tae1a7eefffe6 (\"fetch-pack: signal v2 server that we are done making requests\")\n> \n> Thanks, Kirill!\n> \n> Are you going to report it to the Git community?\n\nJust realized that this discussion is in the Git community :-)\n\n-- \nWith Best Regards,\nAndy Shevchenko\n\n\n"},{"id":"434160","messageId":"YS1Bni+QuZBOgkUI@coredump.intra.peff.net","threadId":"56407","inReplyTo":"20210830182845.pnv7ywnc364jnblt@box","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-30T20:37:50Z","receivedAt":"2021-08-30T20:37:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 30, 2021 at 09:28:45PM +0300, Kirill A. Shutemov wrote:\n\n> > I can't reproduce the problem here, using core.gitproxy with a script\n> > identical to what you showed above. I tried both cloning, and fetching\n> > via both git-fetch and git-fetch-pack.\n> \n> Could you try with a kernel repo?\n> \n> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\n> \n> I found that not all repos on kernel.org trigger the issue.\n\nThanks, I was able to reproduce there (but not with git.git). That makes\nme wonder if it's a race condition of some sort. My reproduction was\njust:\n\n  git init\n  git config core.gitproxy /path/to/proxy/script\n  git fetch-pack \\\n    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \\\n    refs/heads/master\n\nIn the meantime, a workaround is:\n\n  git -c protocol.version=0 fetch-pack ...\n\n> > If you can reproduce it at will and it fails on 2.33 but not earlier,\n> > then bisecting might be helpful.\n> \n> I did. See my other mail.\n\nYeah, looks like you found ae1a7eefff (fetch-pack: signal v2 server that\nwe are done making requests, 2021-05-19). I suspected that might be the\ncase.\n\nI strace'd the underlying socat, and it does this (numbers on the left\nare my annotations):\n\n     select(6, [0 5], [1], [], NULL)         = 2 (in [0], out [1])\n     recvfrom(3, 0x7ffee69f1f50, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)\n     recvfrom(3, 0x7ffee69f19d0, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)\n[0]  read(0, \"\", 8192)                       = 0\n     recvfrom(3, 0x7ffee69f19d0, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)\n[1]  shutdown(5, SHUT_WR)                    = 0\n     recvfrom(3, 0x7ffee69f1f50, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)\n[2]  select(6, [5], [], [], {tv_sec=0, tv_usec=500000}) = 0 (Timeout)\n     recvfrom(3, 0x7ffee69f1f50, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)\n[3]  shutdown(5, SHUT_RDWR)                  = 0\n     recvfrom(3, 0x7ffee69f2240, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)\n     exit_group(0)                           = ?\n\nHere descriptors 0/1 are the pipes from/to Git, and 5 is the TCP socket\nconnected to the server. The recvfrom() is just noise, I think; socat\nopens a dgram socketpair(), but doesn't seem to do anything with it.\n\nSo in [0] we see that Git has hung up half of the pipe, due to the new\ncode in ae1a7eefff. socat then correctly relays the half-duplex shutdown\nto the server in [1]. At this point it should wait for the server to\nsend the data, and relay it to stdout. And indeed, it does call select()\nin [2]. But then when it hits the half-second timeout, it shuts down\ncompletely!\n\nI'm not that familiar with socat, but I've seen the same thing with\nolder versions of netcat: it wants to quit after seeing EOF on stdin.\nThis is useful to prevent deadlock if the server doesn't respond to a\nhalf-duplex shutdown. But it's quite the wrong thing to do for a more\nintelligent protocol.\n\nThat explains why you see the problem sometimes but not others. It\ndepends how long the server takes before it produces any output, which\nin turn may depend on things like repo size. You said you didn't see it\nwhen fetching from GitHub, but I suspect it is simply that GitHub's\nserver responds a little bit more quickly.\n\nIn netcat, the fix is to use \"-q\" (though at least some versions of\nnetcat will wait forever by default these days, so it's not a problem).\nIn socat, it looks like \"-t\" does the same thing. And indeed, switching\nthe proxy to:\n\n  socat -t 10 - \"TCP:$1:$2\"\n\nmakes the problem go away for me. The 10-second timeout might seem\narbitrary, but it should be reliable. Git's server-side has a keep-alive\nmechanism that sends a packet every 5 seconds, even if no output has\nbeen produced yet. So even if the request takes a long time to generate\nany output, it should be plenty to tell socat that the connection is\nstill live.\n\nI am sympathetic that this used to work, and now doesn't. But this proxy\ncase is affected by the problem that ae1a7eefff was solving. The root of\nthe issue is just that \"socat\" in its default form is not doing the\nright thing. So I'd prefer not to try to make any change to Git's\nbehavior here. But one option would be to limit it only to ssh, and not\ngit:// proxies (we already don't do that half-duplex shutdown for raw\nTCP git://, for reasons discussed in that commit message).\n\n-Peff\n"},{"id":"434203","messageId":"20210830224215.hay6rjbt3vk26nk5@box","threadId":"56407","inReplyTo":"YS1Bni+QuZBOgkUI@coredump.intra.peff.net","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Kirill A. Shutemov","fromEmail":"kirill@shutemov.name","sentAt":"2021-08-30T22:42:15Z","receivedAt":"2021-08-30T22:42:20Z","isPatch":false,"sender":{"key":"kirill@shutemov.name","avatar":"https://avatars.githubusercontent.com/u/588661?v=4"},"body":"On Mon, Aug 30, 2021 at 04:37:50PM -0400, Jeff King wrote:\n> I am sympathetic that this used to work, and now doesn't. But this proxy\n> case is affected by the problem that ae1a7eefff was solving. The root of\n> the issue is just that \"socat\" in its default form is not doing the\n> right thing. So I'd prefer not to try to make any change to Git's\n> behavior here.\n\nAs a kernel developer I learned hard way that breaking user experience by\nkernel changes considered a kernel regression, even if userspace \"does it\nwrong\"™. I'm not sure what standard of care for Git users is.\n\nI'm fine adjusting the proxy script and make my colleagues aware about the\nissue, but the approach doesn't scale.\n\n> But one option would be to limit it only to ssh, and not\n> git:// proxies (we already don't do that half-duplex shutdown for raw\n> TCP git://, for reasons discussed in that commit message).\n\nI wounder if it's possible to detect the situation, warn the user that\ngitproxy has to be fixed and retry fetching pack without closing fd[1].\n\n-- \n Kirill A. Shutemov\n"},{"id":"434235","messageId":"YS3GMqz4WHUS0Cjt@coredump.intra.peff.net","threadId":"56407","inReplyTo":"20210830224215.hay6rjbt3vk26nk5@box","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-31T06:03:30Z","receivedAt":"2021-08-31T06:03:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 31, 2021 at 01:42:15AM +0300, Kirill A. Shutemov wrote:\n\n> On Mon, Aug 30, 2021 at 04:37:50PM -0400, Jeff King wrote:\n> > I am sympathetic that this used to work, and now doesn't. But this proxy\n> > case is affected by the problem that ae1a7eefff was solving. The root of\n> > the issue is just that \"socat\" in its default form is not doing the\n> > right thing. So I'd prefer not to try to make any change to Git's\n> > behavior here.\n> \n> As a kernel developer I learned hard way that breaking user experience by\n> kernel changes considered a kernel regression, even if userspace \"does it\n> wrong\"™. I'm not sure what standard of care for Git users is.\n> \n> I'm fine adjusting the proxy script and make my colleagues aware about the\n> issue, but the approach doesn't scale.\n\nI think we're a little less extreme there than the kernel. Like I said,\nmy preference is to leave Git as-is, but if somebody feels strongly, I\ndon't think it would be that hard to leave core.gitproxy untouched here.\n\nI agree it doesn't scale, but my suspicion is that we're talking about\nan extremely small population here. IMHO we should be considering\ndeprecating git:// entirely (from Git itself, and kernel.org should\nconsider turning it off). In the v2 protocol, there's no advantage to\nusing it over HTTP.\n\n> > But one option would be to limit it only to ssh, and not\n> > git:// proxies (we already don't do that half-duplex shutdown for raw\n> > TCP git://, for reasons discussed in that commit message).\n> \n> I wounder if it's possible to detect the situation, warn the user that\n> gitproxy has to be fixed and retry fetching pack without closing fd[1].\n\nI don't think it can be easily distinguished from an actual network\nhangup (or proxy command failure, etc). I would much rather stop doing\nthe close() entirely than add any kind of heuristic retry.\n\n-Peff\n"},{"id":"434251","messageId":"YS3sfzlkTjFXTWVh@smile.fi.intel.com","threadId":"56407","inReplyTo":"YS3GMqz4WHUS0Cjt@coredump.intra.peff.net","subject":"Re: Problem accessing git.kernel.org with git v2.33 plus gitproxy","fromName":"Andy Shevchenko","fromEmail":"andriy.shevchenko@linux.intel.com","sentAt":"2021-08-31T08:46:55Z","receivedAt":"2021-08-31T08:47:02Z","isPatch":false,"sender":{"key":"andriy.shevchenko@linux.intel.com","avatar":"https://gravatar.com/avatar/507bf7f59fddb7004f6bf72b211f6216082913376b9d961221004ab9481d97ca?d=mp&s=160"},"body":"On Tue, Aug 31, 2021 at 02:03:30AM -0400, Jeff King wrote:\n> On Tue, Aug 31, 2021 at 01:42:15AM +0300, Kirill A. Shutemov wrote:\n> > On Mon, Aug 30, 2021 at 04:37:50PM -0400, Jeff King wrote:\n> > > I am sympathetic that this used to work, and now doesn't. But this proxy\n> > > case is affected by the problem that ae1a7eefff was solving. The root of\n> > > the issue is just that \"socat\" in its default form is not doing the\n> > > right thing. So I'd prefer not to try to make any change to Git's\n> > > behavior here.\n> > \n> > As a kernel developer I learned hard way that breaking user experience by\n> > kernel changes considered a kernel regression, even if userspace \"does it\n> > wrong\"™. I'm not sure what standard of care for Git users is.\n> > \n> > I'm fine adjusting the proxy script and make my colleagues aware about the\n> > issue, but the approach doesn't scale.\n> \n> I think we're a little less extreme there than the kernel. Like I said,\n> my preference is to leave Git as-is, but if somebody feels strongly, I\n> don't think it would be that hard to leave core.gitproxy untouched here.\n\nSo far the massive (annoying) Git breakage happened second time to me (*).\nI would agree with you if it's rare to happen, to me it's like once per\n~2 years. So, can you define what the tolerable period of time is when\nI have to expect a Git breakage next time?\n\n(*) First time it was a few years ago when out of a sudden Git started to pull\ngigabytes of repositories without any need. It was annoying, but tolerable to\nsome extent. Current situation is not better form my user perspective.\n\n> I agree it doesn't scale, but my suspicion is that we're talking about\n> an extremely small population here. IMHO we should be considering\n> deprecating git:// entirely (from Git itself, and kernel.org should\n> consider turning it off). In the v2 protocol, there's no advantage to\n> using it over HTTP.\n\nSo far don't you need to support current use cases?\n\n(Here of course a philosophical question: is a driver moves a car, or the car moves the driver)\n\n> > > But one option would be to limit it only to ssh, and not\n> > > git:// proxies (we already don't do that half-duplex shutdown for raw\n> > > TCP git://, for reasons discussed in that commit message).\n> > \n> > I wounder if it's possible to detect the situation, warn the user that\n> > gitproxy has to be fixed and retry fetching pack without closing fd[1].\n> \n> I don't think it can be easily distinguished from an actual network\n> hangup (or proxy command failure, etc). I would much rather stop doing\n> the close() entirely than add any kind of heuristic retry.\n\n-- \nWith Best Regards,\nAndy Shevchenko\n\n\n"}]}