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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux