Ich versuche, einige Änderungen zu schieben, aber git push hängt. Wenn ich git push ausführen, sehe ich keine Ausgabe, und nichts scheint zu passieren. Es gibt keine Aktivität in top und keine Anzeichen von etwas passiert.Git Push hängt über (dumm) https, nach HTTP/1.1 100 Weiter
Ich kontrolliere nicht den Git-Hosting-Service. Ich verwende eine HTTPS-URL. Ich glaube, der Hosting-Service verwendet dumme HTTPS, nicht Git "Smart-HTTP" -Protokoll. Auf der Client-Seite verwende ich Mac OS X, und ich habe git 1.8.1.1 über Homebrew installiert (aber die Verwendung der in den Xcode-Befehlszeilen-Tools enthaltenen git-Version scheint keinen Unterschied zu machen). Abmelden und erneutes Anmelden scheint nicht zu helfen. Ich kann diesen Hosting-Service/Repository von einer anderen Linux-Box aus starten.
Unten ist eine Debugging-Ausgabe, die zeigt git push hängt nach dem Client eine PROPFIND Anfrage ausgibt, bekommt eine HTTP/1.1 100 Continue Antwort vom Server, und dann passiert nichts: es ist nur fest.
Wie bekomme ich das funktioniert? Gibt es irgendwelche Schritte zur Fehlerbehebung, die ich ausprobieren kann?
$ GIT_CURL_VERBOSE=1 git push -v
Pushing to https://secure2.svnrepository.com/redacted/redacted/
* About to connect() to secure2.svnrepository.com port 443 (#0)
* Trying 67.228.18.88...
* Connected to secure2.svnrepository.com (67.228.18.88) port 443 (#0)
* Connected to secure2.svnrepository.com (67.228.18.88) port 443 (#0)
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; OU=Domain Control Validated; CN=secure2.svnrepository.com
* start date: 2012-01-09 16:16:59 GMT
* expire date: 2015-02-09 02:52:45 GMT
* subjectAltName: secure2.svnrepository.com matched
* issuer: O=AlphaSSL; CN=AlphaSSL CA - G2
* SSL certificate verify ok.
> GET /redacted/redacted/info/refs?service=git-receive-pack HTTP/1.1
User-Agent: git/1.8.1.1
Host: secure2.svnrepository.com
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache
< HTTP/1.1 401 Authorization Required
< Date: Wed, 23 Jan 2013 03:29:36 GMT
< Server: Apache/2.2.3 (Red Hat)
< WWW-Authenticate: Basic realm="redacted"
< Content-Length: 493
< Content-Type: text/html; charset=iso-8859-1
<
* Ignoring the response-body
* Connection #0 to host secure2.svnrepository.com left intact
* Issue another request to this URL: 'https://secure2.svnrepository.com/redacted/redacted/info/refs?service=git-receive-pack'
* Re-using existing connection! (#0) with host (nil)
* Connected to (nil) (67.228.18.88) port 443 (#0)
* Server auth using Basic with user 'redacted'
> GET /redacted/redacted/info/refs?service=git-receive-pack HTTP/1.1
Authorization: Basic redacted=
User-Agent: git/1.8.1.1
Host: secure2.svnrepository.com
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache
< HTTP/1.1 200 OK
< Date: Wed, 23 Jan 2013 03:29:36 GMT
< Server: Apache/2.2.3 (Red Hat)
< Last-Modified: Wed, 23 Jan 2013 03:00:40 GMT
< ETag: "143802e-3b-e6374600"
< Accept-Ranges: bytes
< Content-Length: 59
< Content-Type: text/plain; charset=UTF-8
<
* Connection #0 to host (nil) left intact
* Re-using existing connection! (#0) with host (nil)
* Connected to (nil) (67.228.18.88) port 443 (#0)
* Server auth using Basic with user 'redacted'
> GET /redacted/redacted/HEAD HTTP/1.1
Authorization: Basic redacted=
User-Agent: git/1.8.1.1
Host: secure2.svnrepository.com
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache
< HTTP/1.1 200 OK
< Date: Wed, 23 Jan 2013 03:29:36 GMT
< Server: Apache/2.2.3 (Red Hat)
< Last-Modified: Wed, 16 Jan 2013 21:05:31 GMT
< ETag: "d1802c-17-3d0d7cc0"
< Accept-Ranges: bytes
< Content-Length: 23
< Content-Type: text/plain; charset=UTF-8
<
* Connection #0 to host (nil) left intact
* About to connect() to secure2.svnrepository.com port 443 (#0)
* Trying 67.228.18.88...
* Connected to secure2.svnrepository.com (67.228.18.88) port 443 (#0)
* Connected to secure2.svnrepository.com (67.228.18.88) port 443 (#0)
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; OU=Domain Control Validated; CN=secure2.svnrepository.com
* start date: 2012-01-09 16:16:59 GMT
* expire date: 2015-02-09 02:52:45 GMT
* subjectAltName: secure2.svnrepository.com matched
* issuer: O=AlphaSSL; CN=AlphaSSL CA - G2
* SSL certificate verify ok.
> PROPFIND /redacted/redacted/ HTTP/1.1
User-Agent: git/1.8.1.1
Host: secure2.svnrepository.com
Accept: */*
Depth: 0
Content-Type: text/xml
Content-Length: 181
Expect: 100-continue
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 401 Authorization Required
< Date: Wed, 23 Jan 2013 03:29:37 GMT
< Server: Apache/2.2.3 (Red Hat)
< WWW-Authenticate: Basic realm="redacted"
< Content-Length: 493
< Content-Type: text/html; charset=iso-8859-1
* the ioctl callback returned 0
<
* Ignoring the response-body
* Connection #0 to host secure2.svnrepository.com left intact
* Issue another request to this URL: 'https://secure2.svnrepository.com/redacted/redacted/'
* Re-using existing connection! (#0) with host (nil)
* Connected to (nil) (67.228.18.88) port 443 (#0)
* Server auth using Basic with user 'redacted'
> PROPFIND /redacted/redacted/ HTTP/1.1
Authorization: Basic redacted=
User-Agent: git/1.8.1.1
Host: secure2.svnrepository.com
Accept: */*
Depth: 0
Content-Type: text/xml
Content-Length: 181
Expect: 100-continue
< HTTP/1.1 100 Continue
Ich habe nicht strace auf meinem Mac OS X-Maschine, und ich kann nicht herausfinden, wie dtruss zu verwenden, um zu sehen, welches System fordert er hängt da dtruss mich erfordert Wurzel zu sein, und dann Git Push wird anders funktionieren.
Update: Ich habe dies auf einer Linux-Maschine mit Git 1.8.1.4 und mit Strace reproduziert. strace Lauf zeigt so etwas wie die folgenden, bevor es aufhängt:
sendto(4, <redacted>..., 314, 0, NULL, 0) = 314
recvfrom(4, "\27\3\1\0000", 5, 0, NULL, NULL) = 5
recvfrom(4, "E\202\271\21\236p\200\346\374\3641\355\t\275\rLi\202T)\326\271l/\351\f\357\2769Jb\22"..., 48, 0, NULL, NULL) = 48
select(5, [4], [4], [], {0, 729000}) = 1 (out [4], left {0, 728997})
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=4, events=POLLOUT|POLLWRNORM}], 2, 0) = 1 ([{fd=4, revents=POLLOUT|POLLWRNORM}])
select(5, [4], [], [], {0, 729000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
...last 2 lines repeat infinitely...
So scheint es, etwas von dem Server zu empfangen erwartet zu hängen.
Auch habe ich eine ähnliche Spur mit GIT_CURL_VERBOSE=1 git push -v auf einer älteren Linux-Box mit Git 1.7.4.4 versucht, und es beginnt mit dem gleichen Präfix und fährt dann von dort fort. Auf der defekte Maschine mit dem neueren git:
$ grep '^> [A-Z]' git-1.8.1.1-trace.stderr
> GET /redacted/redacted/info/refs?service=git-receive-pack HTTP/1.1
> GET /redacted/redacted/info/refs?service=git-receive-pack HTTP/1.1
> GET /redacted/redacted/HEAD HTTP/1.1
> PROPFIND /redacted/redacted/ HTTP/1.1
> PROPFIND /redacted/redacted/ HTTP/1.1
auf der älteren Maschine mit dem älteren git, wo alles Arbeits ist:
$ grep '^> [A-Z]' git-1.7.4.4-trace.stderr
> GET /g_wagner/c79-s13/info/refs?service=git-receive-pack HTTP/1.1
> GET /g_wagner/c79-s13/info/refs?service=git-receive-pack HTTP/1.1
> GET /g_wagner/c79-s13/HEAD HTTP/1.1
> PROPFIND /g_wagner/c79-s13/ HTTP/1.1
> PROPFIND /g_wagner/c79-s13/ HTTP/1.1
> HEAD /g_wagner/c79-s13/info/refs HTTP/1.1
> HEAD /g_wagner/c79-s13/objects/info/packs HTTP/1.1
> MKCOL /g_wagner/c79-s13/info/ HTTP/1.1
> LOCK /g_wagner/c79-s13/info/refs HTTP/1.1
> GET /g_wagner/c79-s13/objects/info/packs HTTP/1.1
...
> UNLOCK /g_wagner/c79-s13/info/refs HTTP/1.1
bei der vollen Spur Blick auf beiden Maschinen, kann ich nicht irgendeinen Unterschied in dem, was in der problematischen PROPFIND-Anfrage (der 2. PROPFIND) gesendet wird: Beide Anfragen scheinen identisch zu sein, mit Ausnahme des Headers User-Agent:.
'
cjc343
Danke, @ cjc343. Irgendwelche Tipps zur weiteren Problembehandlung? Ich benutze '~/.netrc' für die Authentifizierung, und ich habe bestätigt, dass mein' ~/.netrc' genau mit seinem Wert auf einem anderen (Linux) Rechner identisch ist, auf dem ich kein Problem habe. Ich bin auch in der Lage, erfolgreich von dieser Maschine zu ziehen, die auch Authentifizierungsnachweise erfordern würde - so ist es alles sehr verwirrend. –
Es ist sicherlich merkwürdig ... Leider bin ich nicht vertraut mit Git über http/s, da ich immer ssh für die Authentifizierung verwendet habe. Wenn Pull-Berechtigungen nicht versehentlich offen gelassen werden, macht es keinen Sinn, dass Sie nicht pushen können und die meisten Möglichkeiten ausschaltet, wie Berechtigungen für '.netrc', die zu weit geöffnet sind oder einen Benutzernamen, der in der Fernbedienung enthalten ist oben, wenn es der Fall wäre), aus dem Fenster. Wenn du eine Fernbedienung hinzufügst, die den Benutzernamen enthält, fragt dich git nach dem Passwort beim Drücken (sollte es)? Hoffentlich hat jemand anderes eine bessere Vorstellung von dem, was schief geht ... – cjc343