Tại sao git-upload-pack (trong khi git clone) bị treo?

Question

Tôi đã đọc một số câu hỏi khác 'git treo trên clone', nhưng không ai phù hợp với môi trường và chi tiết của tôi. Tôi đang sử dụng git xây dựng theo Cygwin (msys git không phải là một lựa chọn) để sao chép một repo từ một máy chủ Linux qua SSH.

git clone user@host:repo 

Tôi đã thử nghiệm trên cùng một máy chủ trên các nền tảng khác và hoạt động tốt, nhưng trên máy tính Windows này bản sao bị treo vô thời hạn. Tôi đặt GIT_TRACE=1 và có vẻ như vấn đề là với lệnh này:

'ssh' 'user@host' 'git-upload-pack '\''repo'\''' 

khóa SSH của tôi được thiết lập một cách chính xác: ssh user@host hoạt động tốt. Khi tôi chạy lệnh, tôi nhận được một loạt đầu ra kết thúc như sau:

... 
003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start 
0000 

Sau đó, nó bị treo trong 20 phút, dài nhất mà tôi đã chờ trước khi tiêu diệt.

Máy chủ có Git 1.7.11.7 với OpenSSH 5.9p1, trong khi máy khách có Git 1.7.9 với OpenSSH 6.1p1.

Đó có phải là kết thúc của đầu ra git-upload-pack không? Đây có phải là lỗi trong Git hoặc cấu hình của tôi không?

Answer 1

Chúng tôi đã phải đối mặt với một vấn đề tương tự - và chúng tôi gán cho nó như sau: git repo của chúng tôi có rất nhiều tệp nhị phân được đăng ký (nhiều phiên bản, trong 1,5 năm qua của dự án này). Vì vậy, chúng tôi cho rằng đây là nguyên nhân.

Để hỗ trợ lý thuyết này, chúng tôi có các cơ sở mã khác gần đây hơn (và do đó không có quá nhiều tệp nhị phân và phiên bản của chúng) - không thể hiện hành vi này.

Thiết lập của chúng tôi: Thiết lập Git trên Linux, VPN từ trang web đến điểm giữa London và Ấn Độ qua đường T1.

Answer 2

Phiên bản git1.8.5 sắp tới (Q4 2013) sẽ ghi lại giao thức http thông minh hơn.
Xem commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 bởi Shawn O. Pearce.

Với tài liệu chi tiết đó, ý tưởng sẽ là theo dõi các yêu cầu web được thực hiện giữa máy khách git và máy chủ của bạn và xem liệu các yêu cầu đó có tuân theo những gì được ghi dưới đây hay không.

Điều đó có thể giúp xác định nơi dịch vụ "treo".

---

File Documentation/technical/http-protocol.txt khăng khăng:

• các "Smart Service git-upload-pack" đầu tiên

  • Khách hàng phải thực hiện khám phá ref với '$GIT_URL/info/refs?service=git-upload-pack'.

    C: POST $GIT_URL/git-upload-pack HTTP/1.0 
    S: 200 OK 
    S: Content-Type: application/x-git-upload-pack-result 
    S: Cache-Control: no-cache 
    S: 
    S: ....ACK %s, continue 
    S: ....NAK 
    

  • Khách hàng PHẢI KHÔNG tái sử dụng hoặc hợp lệ lại một phản ứng cache.

  • Máy chủ PHẢI bao gồm đủ tiêu đề Bộ nhớ cache kiểm soát để ngăn bộ nhớ đệm của phản hồi.
  • Máy chủ NÊN hỗ trợ tất cả các khả năng được xác định tại đây.
  • Khách hàng PHẢI gửi ít nhất một lệnh 'muốn' trong phần thân yêu cầu.
  • Khách hàng KHÔNG ĐƯỢC tham chiếu một id trong lệnh 'muốn' không xuất hiện trong phản hồi thu được thông qua khám phá ref trừ khi máy chủ quảng cáo khả năng "allow-tip-sha1-in-want".

• Các "negociation" algorithm

  (c) Send one $GIT_URL/git-upload-pack request: 
  C: 0032want <WANT #1>............................... 
  

Answer 3

Tôi đã có vấn đề này cùng sau khi tôi thêm một số nhạc jazz như thế này để cấu hình ssh của tôi để thiết lập tiêu đề cửa sổ trong tmux:

Host * 
PermitLocalCommand yes 
LocalCommand if [[ $TERM == screen* ]]; then printf "\033k%h\033\\"; fi 

loại bỏ điều đó đã sửa lỗi git của tôi.

Answer 4

PuTTy đã lỗi thời cũng có thể gây ra điều này. Hệ thống của bạn có thể đang sử dụng plink.exe làm GIT_SSH.

Bạn có thể cài đặt phiên bản phát triển mới nhất từ ​​http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html để đảm bảo đây không phải là vấn đề.

Answer 5

Điều này có tác dụng đối với tôi, trong trường hợp nó giúp người khác.

Kiểm tra url từ xa git của bạn. Nó có thể treo với git-upload-pack trên một dấu vết nếu bạn sử dụng loại url sai. thay đổi url từ git@github.com: thành https://github.com/ trên điều khiển từ xa của bạn.