On 2021-10-18 at 19:34:59, Jeff King wrote: > I recently saw a case where GitHub's server implementation failed to > correctly report ref statuses. In this case it was because it hit an > internal timeout, but the root cause doesn't really matter; the server > is doing the wrong thing. > > But what's interesting on the Git client side is that we produce quite a > confusing message for http. For ssh, we correctly say something like (in > this example, I'm pushing an absurd number of tags that causes the > timeout): > > To ssh://github.com/some/repo > ! [remote failure] tag-1 -> tag-1 (remote failed to report status) > [...etc...] > ! [remote failure] tag-999 -> tag-999 (remote failed to report status) > error: failed to push some refs to 'ssh://github.com/some/repo' > > but for http, I get just: > > Everything up-to-date > > Which is misleading to say the least. The issue is communication between > send-pack and remote-curl on the client side. > > The first patch does the minimal fix. The second one has some cosmetic > improvements. They arguably could be squashed together, but I think > keeping them split shows exactly what the second patch is actually > accomplishing (especially with the minor change to the expected output > in the test). > > This bug has been around since smart http was added in 2009. I just > prepared it on master, but I expect it could also go to maint. This seems sane to me, and I'm delighted you managed to add a test for this case (which I was not expecting to be possible). -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature