Re: [PATCH 0/2] handling REF_STATUS_EXPECTING_REPORT over http

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