On Mon, Jul 26 2021, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > On 2021-07-26 at 17:54:07, Evan Miller wrote: >> What did you do before the bug happened? (Steps to reproduce your issue) >> >> $ git clone -v git@xxxxxxxxxx:macports/macports-ports.git >> Cloning into 'macports-ports'... >> remote: Enumerating objects: 1223319, done. >> remote: Counting objects: 100% (685/685), done. >> remote: Compressing objects: 100% (341/341), done. >> remote: Total 1223319 (delta 289), reused 608 (delta 252), pack-reused 1222634 >> Receiving objects: 100% (1223319/1223319), 244.46 MiB | 1.09 MiB/s, done. >> Connection to github.com closed by remote host. > > This message is the relevant detail here. This means that the > connection was reset, which could be due to the remote host (GitHub), > but is more likely due to a network issue of some sort. You'll have to > do normal network troubleshooting to see why that might be. > > It could very well be related to the fact that you're running a nearly > 14-year old operating system, but I just can't say for certain. It's > not a bug in Git, however. I'm not so sure it's not, I think the "Connection to github.com closed by remote host" message is emitted by the C library, not Git itself (we don't seem to have that exact wording anywhere, but maybe I missed it). I've seen other cases where I think OSX in particular is quite verbose in this area, but maybe I'm misrecalling. We've already received all objects as noted downthread, so having the connection go away should be something we handle gracefully, and the code in transport.c seems to try to do that. It's also quite unusual for us to exit with code 255, I don't think we do that intentionally anywhere (not from die, BUG etc.). Evan: Can you run this with some of GIT_TRACE=1 / GIT_TRACE_EVENT=/dev/stderr GIT_TRACE_PACKET=1 and see if some of those show what's happening in/around that 255 exit?
