git push nie abgeschlossen - wird nur auf Gesamtleitung

Question

Erwartetes Verhalten

I edited file1, engagiert, und tat dies

$ git push 

NOTICE: Only authorized blah blah blah... 

Counting objects: 7, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (7/7), done. 
Writing objects: 100% (7/7), 676 bytes | 0 bytes/s, done. 
Total 7 (delta 4), reused 0 (delta 0) 
To ssh://me@server:/opt/git/fooBar.git 
    28ad03d..73ae492 master -> master 
$ 

Problem

Dann bearbeiten ich file2 im selben Projekt, verpflichtet und tat dies:

$ git push 

NOTICE: Only authorized blah blah blah... 

Counting objects: 10, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (8/8), done. 
Writing objects: 100% (10/10), 1.42 KiB | 0 bytes/s, done. 
Total 10 (delta 4), reused 0 (delta 0) 
^C 

Beachten Sie, wie ich zu CTRL-C hatte (^C) am Ende? Das ist, weil es nie abgeschlossen wurde. Dies ist NICHT das erwartete Verhalten.

fehlgeschlagen Bewältigungsmechanismen

So I:

cd .. 
mv fooBar/ fooBar_bak/ 
git clone ssh://me@server:/opt/git/fooBar.git 
cd fooBar 

bearbeiten einige andere Textdatei (nur eine leere Zeile hinzugefügt), gedrückt, und es funktionierte. Dies bedeutet, dass ich nach dem fehlgeschlagenen Push einen erfolgreichen Push von/zu denselben lokalen/entfernten Repositories vor und durchgeführt habe.

Aber bearbeiten Sie Datei2, die es vorher nicht mochte? Der Push wird nie abgeschlossen. Das Gleiche gilt für Datei3, die es auch nicht mag. Ich sehe nichts besonderes an diesen Dateien.

Nun, Datei2 und Datei3 sind UTF-8 und Datei1 ist ASCII, aber das sollte keine Rolle spielen. Sollte es?

Ich versuchte alle Lösungen bei git push hangs after Total line, aber keine funktionierte für mich.

Ich habe nicht wirklich die Ausgabe von strace -efile -f git push verstanden, aber nichts sprang auf mich.

Ich wartete. Aber das ist kein großes Repo oder eine große Datei.

Ich benutze Ubuntu 16.04 mit git Version 2.7.4 auf meinem Rechner und git Version 1.7.1 auf dem CentOS Server. Ich habe keine msysgit, git-for-windows oder cygwin installiert.

git push -u origin master hat auch nicht funktioniert.

git config http.postBuffer 524288000 machte keinen Unterschied.

GIT_CURL_VERBOSE=1 und GIT_TRACE=1 hatten keine Wirkung.

git config --global core.askpass "git-gui --askpass" habe nichts getan, wahrscheinlich weil ich git-gui nicht installiert habe.

@ RonanDejhero's Vorschlag hier: https://stackoverflow.com/a/21032615/1128668 war, was mir erlaubt zu sehen, dass einige Dateien geändert werden können, verpflichtet und geschoben und einige können nicht. Ich habe versucht, die geänderten Dateien zu kopieren, die Dateien manuell zu ändern und geringfügig andere Änderungen vorzunehmen: nicht gut.

Auf dem Server tat ich sudo chown -R me.git-users /opt/git/, aber das machte auch keinen Unterschied. Wenn ich in der Vergangenheit solche Probleme hatte, schien das zu helfen.

Ich habe eine git gc in meinem lokalen Repo und auf dem Server in /opt/git/fooBar.git. Keine Freude.

aktualisieren

Ich löschte meine lokalen Repo, geklont, bearbeitet file2 (die git nicht, bevor sie bearbeitet haben mögen) von nur eine leere Zeile hinzufügen. Engagiert, gedrückt, es hat funktioniert! Dann habe ich ein Dutzend Zeilen unbenutzten Code auskommentiert, den ich geschoben habe, und es hat funktioniert! Könnte ich einen Charakter oder etwas eingeführt haben, das Git nicht mochte?

Answer 1

Es war mein Router?!?!?!

Der größte Hinweis war, dass ich versuchte, eine der lästigen Dateien SFTP bis zum Server und es schlug fehl. Ich hatte gestern einen neuen Netgear AC1750 Smart WLAN Router Modell R6400 installiert. Um mein Problem zu beheben, habe ich einfach den Netgear Router ausgesteckt und meinen alten Linksys WRT120N eingesteckt. Alles hat funktioniert.

Seltsam. Sie würden denken, wenn ich ein VPN von meinem Desktop benutze und SSH innerhalb davon laufen lasse, würde der Fräser nicht in der Lage sein zu sagen, welche Art von Paket es sendet. Oder wenn es Pakete vermasselt, die alles kaputt machen würden. Ich verstehe es nicht.

Ich sagte Netgear über mein Problem und wies darauf hin, dass ich den Router zurückgeben und etwas bekommen könnte ich Open-Source-Firmware auf installieren. Ihre Antwort lautete: "Vielleicht sollten Sie das tun", also tat ich es. Glücklich läuft OpenWRT auf einem Buffalo-Router jetzt mit allem, was funktioniert. für alle meine git repos

Answer 2

hatte ich dieses Verhalten für einen anderen Grund, hoffentlich jemand diese Antwort hilft sonst :)

ich auf meinem lokalen Git-Server zu Hause auf/srv/git ein Verzeichnis haben, und Benutzer mit dem Namen Git-Benutzer, der alle Dateien besitzt. Ich sehe URLs wie ssh: // git-user @ server/repo, um die Repos zu klonen und Änderungen vorzunehmen, die garantieren, dass git-user alle Dateien besitzt.

Ich habe für jedes meiner Repos von SVN zu GIT gewechselt. Mein Flow zur Herstellung eines neuen Repo von den neuesten Dateien von einem SVN-Repo (I do not care über die Geschichte, sie sind nur persönliche Projekte) ist wie folgt:

ssh <git server> 
su - 
su - git-user 
git init --bare newgitrepo.git 
exit 

# Back to my desktop 
cd git 
git clone ssh://git-user@<git server>/srv/git/newgitrepo.git 
cd newgitrepo 
# Set up initial files - my local Workspace dir is where Eclipse has 
# SVN projects already checked out 
cp -r ../Workspace/<svn repo>/* . 
cp ../Workspace/<svn repo>/<hidden dot files/dirs, except for .svn> . 
# Create .gitignore files for stuff like compiled code directory 
git add <everything but .git dir> 
git commit -m 'Initial Import' 
git push origin master 

ich einen Fall von einem Repo hatten dass ich einfach nichts schieben konnte, ohne dieses irritierende Verhalten einer totalen Linie und keine weitere Reaktion zu bekommen. Ich hatte den 3. Befehl auf dem Server verpasst (su-git-user), also hatte ich mein blankes Repo als root erstellt, was dazu führte, dass alle Dateien im Besitz von root waren. Die Lösung war natürlich einfach das leere Repo auf dem Server zu löschen und als git-user neu zu erstellen.

Dies steht damit in Verbindung, was GlenPeterson über dieses Serverproblem sagte, und nicht ein Clientproblem.