On Thu, Nov 14, 2024 at 11:37:50PM +0000, brian m. carlson wrote: > The only thing which might potentially be a problem on the Git side is > that I don't know if we try to hold the connection open without sending > a sideband during pack generation, in which case if the client side > doesn't send anything at all, then the connection might be closed by the > server. I'll point out that GitHub sends SSH keepalives, so typically > the connection should not be reset unless the connection actually > drops. Yes, we'll hold the connection open for git-over-ssh. We can't generate the pack until we've seen what the other side advertises, and it's probably too heavy-weight to start a second ssh connection. Even with ssh keepalives, I would not be surprised if the process terminating the Git-level protocol conversation on the server side had some internal timeouts. There are Git-level keepalives during the similar compression operation of a clone/fetch, as well as the delta resolution for the server side of a push. But there's nothing during the client-side compression. I know we've discussed this on the list before, but I couldn't find anything substantive, and certainly not patches. I think it would _probably_ work for the client to send 0-length pktlines (actual "0004", not "0000" flushes) every few seconds while it's waiting. But it would be the first time we've done so from the client side, and the first time we've done it outside of sideband framing. So it's possible a server might not like it (in which case we'd probably need a new protocol extension). > Overall, I would not say this is a bug in Git. Pushing over HTTPS may > help you get your pushes working in a more robust way, but in general, > I'd recommend storing the data in your repository differently. I agree with everything you said, but I wanted to add one more workaround: running "git gc" locally will pack all of those objects into a single pack. And then the subsequent push should be fast, because we'll already have done the delta search. -Peff
