2

I'm new to git and I want to create a repo on gitlab. I've created a new project and added an ssh key. created a new directory in my Desktop. but when I use this command:

git clone https://gitlab.com ...

it shows:

Cloning into ...

and nothing happens next. it stuck. but I can clone into other repo ( made by others on the internet). why I can't clone into my repo?

MHB
  • 625
  • 2
  • 10
  • 20
  • how big is the remote repo? how long did you wait? – mnagel Aug 17 '19 at 08:19
  • it is only initialized with readme @mnagel – MHB Aug 17 '19 at 08:32
  • Is `git clone https://gitlab.com ...` literally the command you used? If yes, it has two problems. First, `https://gitlab.com` is not a valid repository url. It's expected to be `https://gitlab.com/foo/bar.git` where `foo` is your username or group name and `bar.git` is the repository name. Second, `...` would creates a local folder named `...` which is not a good name. If `...` is omitted, `bar` is the default name. – ElpieKay Aug 17 '19 at 09:28
  • that is not literally what I use, it is git clone HTTP key – MHB Aug 17 '19 at 15:10
  • It sounds like your system is waiting to make the connection, i.e., the trouble is somewhere in your networking stack. Check that you can make a connection of the desired type (https, http, ssh, whatever protocol you've selected) to the server host, using whatever network-connection-diagnostic tools your system has. – torek Aug 17 '19 at 18:43
  • 1
    Try `GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone https://gitlab.com`. That should provide some additional debug output. It will likely confirm that something is blocking your connection to GitLab.com, as the last commenter suggested. – Drew Blessing Aug 19 '19 at 20:13

1 Answers1

1

Since GitHub or GitLab support the v2 protocol, you can get into these kind of deadlock with said v2.

Before Git 2.28 (Q3 2020), the on-the-wire protocol v2 easily falls into a deadlock between the remote-curl helper and the fetch-pack process when the server side prematurely throws an error and disconnects.

The communication has been updated to make it more robust.

See commit b0df0c1, commit 0181b60, commit 74b082a, commit 101736a, commit dde72f9 (19 May 2020), and commit 04cc91a, commit 51ca7f8 (18 May 2020) by Denton Liu (Denton-L).
(Merged by Junio C Hamano -- gitster -- in commit b37fd14, 09 Jun 2020)

stateless-connect: send response end packet

Reported-by: Force Charlie
Helped-by: Jeff King
Signed-off-by: Denton Liu

Currently, remote-curl acts as a proxy and blindly forwards packets between an HTTP server and fetch-pack.
In the case of a stateless RPC connection where the connection is terminated before the transaction is complete, remote-curl will blindly forward the packets before waiting on more input from fetch-pack.
Meanwhile, fetch-pack will read the transaction and continue reading, expecting more input to continue the transaction.

This results in a deadlock between the two processes.

(Hence your issue)

This can be seen in the following command which does not terminate:

$ git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012
  Cloning into 'git'...

whereas the v1 version does terminate 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

Instead of blindly forwarding packets, make remote-curl insert a response end packet after proxying the responses from the remote server when using stateless_connect().
On the RPC client side, ensure that each response ends as described.

A separate control packet is chosen because we need to be able to differentiate between what the remote server sends and remote-curl's control packets.
By ensuring in the remote-curl code that a server cannot send response end packets, we prevent a malicious server from being able to perform a denial of service attack in which they spoof a response end packet and cause the described deadlock to happen.

So your case should not happen anymore with Git 2.28: if the clone has to fail, it will do so explicitily instead of staying "frozen" forever.

Note: with Git 2.33 (Q3 2021), the error message has been updated.

See commit 8232a0f (08 Jul 2021) by Denton Liu (Denton-L).
(Merged by Junio C Hamano -- gitster -- in commit 1e893a1, 28 Jul 2021)

pkt-line: replace "stateless separator" with "response end"

Signed-off-by: Denton Liu

In 0181b60 (pkt-line: define PACKET_READ_RESPONSE_END, 2020-05-19, Git v2.28.0-rc0 -- merge listed in batch #2) (pkt-line: define PACKET_READ_RESPONSE_END 2020-05-19), the Response End packet was defined for Git's network protocol.
When the patch was sent, it included an oversight where the error messages referenced "stateless separator", the work-in-progress name, over "response end", the final name chosen.

Correct these error messages by having them correctly reference a "response end" packet.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250