Dlaczego git-upload-pack (podczas klonowania git) zawiesił się?

Question

Przeczytałem kilka innych pytań "git zawiesza się na klonie", ale żadne nie pasują do mojego środowiska i szczegółów. Używam gita zbudowanego pod cygwin (msys git nie jest opcją) do klonowania repozytorium z hosta Linux przez SSH.

Testowałem na tym samym hoście na innych platformach i działa dobrze, ale na tym komputerze z systemem Windows klon wisi w nieskończoność. Ustawić GIT_TRACE=1 i wygląda na to, że problem jest z tym poleceniem:

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

klucze SSH są ustawione prawidłowo: ssh user@host działa dobrze. Kiedy uruchomić komendę, mam kilka produkcji, które kończy się tak:

... 
003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start 
0000 

Wtedy to wisi na ponad 20 minut, co jest najdłuższym Czekałam przed zabiciem go.

Serwer ma Git 1.7.11.7 z OpenSSH 5.9p1, a klient ma Git 1.7.9 z OpenSSH 6.1p1.

Czy to ma być koniec pliku wyjściowego git-upload-pack? Czy jest to błąd w Git lub mojej konfiguracji?

Answer 1

Podejdziemy do podobnego problemu - i przypisaliśmy to następująco: Nasze repozytorium git zawiera wiele plików binarnych (wiele wersji, w ciągu ostatnich 1,5 roku tego projektu). Tak więc przyjęliśmy, że to była przyczyna.

Aby wesprzeć tę teorię, mamy inne podstawy kodu, które są nowsze (a więc nie mają tylu plików binarnych i ich wersji) - które nie wykazują takiego zachowania.

Nasza konfiguracja: Konfiguracja Git na Linuksie, połączenie VPN między lokacjami od Londynu do Indii przez linię T1.

Answer 2

Nadchodzący Git1.8.5 (Q4 2013) udokumentuje bardziej inteligentny protokół http.
Zobacz commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 przez Shawn O. Pearce.

Dzięki tej szczegółowej dokumentacji, pomysł polegałby na monitorowaniu żądań sieciowych wykonanych między klientem git a serwerem i sprawdzeniu, czy są one zgodne z tym, co jest udokumentowane poniżej.

Może to pomóc w ustaleniu, gdzie usługa "zawiesza się".

---

Plik Documentation/technical/http-protocol.txt kładzie nacisk na:

• się "Smart Service git-upload-pack"

  • klienci muszą najpierw wykonać ref odkrycia z '$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 
    

  • klienci nie muszą ponownie wykorzystać lub revalidate buforowanej réponse.

  • Serwery MUSZĄ zawierać wystarczającą liczbę nagłówków Kontroli pamięci podręcznej , aby zapobiec buforowaniu odpowiedzi.
  • Serwery POWINNY wspierać wszystkie zdefiniowane tutaj możliwości.
  • Klienci MUSZĄ wysłać co najmniej jedno polecenie "chcę" w treści żądania.
  • Klienci NIE POWINIEN odwoływać się do identyfikatora w komendzie "chcę", która nie pojawiła się w odpowiedzi uzyskanej przez odkrycie, chyba że serwer anonsuje opcję "allow-tip-sha1-in-want".

• "negociation" algorithm

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

Answer 3

miałem ten sam problem po dodaniu trochę jazzu jak to do mojego ssh config w celu ustalenia tytułów okien w tmux:

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

pozbyłem się tego, naprawiłem mój git.

Answer 4

Może to również spowodować przestarzały PuTTy. Twój system może używać plink.exe jako GIT_SSH.

Możesz zainstalować najnowszą wersję kompilacji z http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html, aby upewnić się, że to nie jest problem.

Answer 5

To zadziałało, pomóż komuś innemu.

Sprawdź swój zdalny adres URL git. Może się zawiesić z git-upload-pack na śladzie, jeśli używasz niewłaściwego typu adresu URL. zmień adres URL z git@github.com: na https://github.com/ na pilocie.