On Wed, Nov 13, 2019 at 09:00:52AM +0800, Force.Charlie wrote: > Recently, when I tested my Git Over HTTP server, I found a bug in Git. When we used git -c protocol.version=2 clone --shallow-since , if the time format is wrong, it will cause git to wait indefinitely. > > Github supports Wire Protocol to reproduce, Gitlab does not support it and does not reproduce it. > > The commands that can be retried are as follows: > > ```shell > # time format wrong > git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012 > # trace > GIT_TRACE=1 GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=2 git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012 > ``` > We can see that the server closes the HTTP connection after sending the `shallow-info\n` message, and git-remote-http(s) is still waiting. > > ``` > $ git --version --build-options > git version 2.24.0 > cpu: x86_64 > no commit associated with this build > sizeof-long: 8 > sizeof-size_t: 8 > > ``` > > When the time format is correct, the clone is successful, so this is followed by the shallow-list： > > ```shell > GIT_TRACE=1 GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=2 git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=2015-10-12 > ``` > > Github Issues: https://github.com/gitgitgadget/git/issues/457 FWIW, I can reproduce this issue as well. From what I can tell (without actually looking at any code), it seems like when an invalid `--shallow-since` is given to the server, it'll hang up on the client. With protocol v1, the client quits as expected: $ git -c protocol.version=1 clone https://github.com/git/git.git --shallow-since=20151012 Cloning into 'git'... fatal: the remote end hung up unexpectedly However, with v2, I believe that the client doesn't detect the hang up and just waits forever. Unfortunately, I don't know the networking code at all and I don't have time to actually dig into the code. Hopefully this helps a little bit, though. Thanks, Denton
