Git Push führt zu fatal: Protokollfehler: Zeichen für schlechte Leitungslänge: Dies

Nur für andere Benutzer Referenz:

fatal: protocol error: bad line length character: no s
can be a truncated answer for "No such project".

Wie in meinem Fall kann dieser Fehler behoben werden, indem dem Projekt in gitlab ein Benutzer (sogar Sie selbst) hinzugefügt wird:

https://gitlab.com/username/your_project/project_members

stellen Sie außerdem sicher, dass Ihr öffentlicher Schlüssel in Ihrem Benutzer festgelegt ist. Profile settings > SSH Key or in Project > Settings > Deploy Keys

https://gitlab.com/profile/keys

Eine weitere Sache, die Sie überprüfen müssen, ist, dass Ihre .bashrc keine zusätzlichen Dateien druckt

[email protected]:~/malt$ ssh snake01
Last login: Tue Oct 21 10:44:31 2014 from 138.15.166.103
hello
...
[email protected]:/net/snake01/usr/hydra/kruus/malt$ git pull
fatal: protocol error: bad line length character: hell

Beachten Sie, wie das Hallo sagen zu einem großen Problem geführt hat.

Wenn Sie das "Echo" Hallo "aus meinem .bashrc entfernen, kann git wieder wie erwartet arbeiten. Möglicherweise müssen Sie "&/dev/null" entfernen, um die Ausgabe zu entfernen, wenn Ihre .bashrc kompliziertere Aufgaben ausführt.

Eine andere Möglichkeit ist, dass Sie den Repository-Namen falsch geschrieben haben.

Ich habe es in den letzten zwei Tagen zweimal gemacht. Ich habe eine Fernbedienung hinzugefügt und sie falsch geschrieben und den Namen beim Erstellen des Projekts in GitLab falsch geschrieben.

In beiden Fällen bekam ich, als ich versuchte, auf Remote zu schieben

fatal: protocol error: bad line length character: No s

Also die Rechtschreibung überprüfen!

Wenn Sie das Projekt unter einem anderen Namen erstellen (z. B. einer Gruppe), stellen Sie sicher, dass es sich um die entfernte Fernbedienung handelt.

Sie können die eigentliche Fehlermeldung erhalten, indem Sie Folgendes tun:

ssh [email protected] "git-upload-pack yournamespace/yourreponame.git"

Laut dieser git-Dokumentation erwartet das git-Protokoll am Anfang jeder Zeile seine Größe und dann den Inhalt. Sieht aus, als würde GitLab das nicht tun und sendet die Fehlermeldung direkt. 

Die Lösung meines Problems bestand darin, dass ich vergessen hatte, einen Bereitstellungsschlüssel für das Projekt hinzuzufügen (für den Benutzer, den ich als bereitstellen wollte).

Hinzufügen eines Bereitstellungsschlüssels in https: // gitlab/group/project/deploy_keys .

Ich habe diese Fehlermeldung heute erlebt ("Nein"), und es hatte tatsächlich mit mir zu tun, dass ich keine Rechte hatte, um auf das Ziel-Repository zu pushen. Obwohl die Fehlermeldung sehr seltsam ist, kann dies den Leuten helfen, weiterzuarbeiten.

Wir verwenden Gitlab.

Sudo gitlab-ctl reconfigure

und dann

Sudo gitlab-ctl restart

sollte den Trick tun

In meinem Fall wurde mein Benutzername geändert und die git config dieses Repositorys wurde nicht aktualisiert, um mit dem neuen Namen übereinzustimmen.

Überprüfen Sie Ihre Git-Fernbedienungen, um sicherzustellen, dass sie auf den richtigen Ort zeigen:

git remote -v

Aktualisieren Sie die Konfiguration, indem Sie die Konfiguration manuell bearbeiten:

vim .git/config

oder durch Befehle

git remote set-url Origin https://github.com/USERNAME/OTHERREPOSITORY.git

In meinem Fall (privater Schlüssel über ~/.ssh/config) musste ich den SSH-Teil auslassen:

git clone ssh://[email protected]:username/repository.git

Es funktionierte mit:

git clone [email protected]:username/repository.git

Fehlermeldung war:

fatal: Protokollfehler: Zeichen für schlechte Leitungslänge: Nein

Ändern Sie die Shell von Git

usermod -s /usr/bin/git-Shell git

Ich hatte das gleiche Problem und stellte fest, dass ich in einem Git-Zweig arbeitete. Alles, was ich tun musste, war Push an den Meister. 

$ git Push <remote> <local branch name>:<remote branch to Push into>

Hatte das gleiche Problem, in meinem Fall war das Origin-Repo verschoben worden.

In meinem Fall habe ich diesen Fehler nur in "SSH-Erweiterungen" für Windows beobachtet.

Der gleiche Befehl funktionierte von der Befehlszeile aus. Ich habe die SSH-Einstellung von PuTTY auf OpenSSH umgestellt und der Fehler wurde abgebrochen.

In meinem Fall wurde dieser Fehler behoben, indem die entfernte git-user-Shell mit chsh in git-Shell geändert wurde:

chsh -s $(command -v git-Shell) git

Offizieller git-ShellDokumentation . Aus Sicherheitsgründen wird dringend empfohlen, diese Shell für git-user auf einem Remote-Repository-Server zu verwenden.

Als ich meine Commits pushen wollte, bekam ich diesen Fehler

fatal: protocol error: bad line length character: No s

Ich habe dies nur durch eine SSH-Verbindungsprüfung gelöst:

ssh [email protected]

Mein Fehler war: fatal: protocol error: bad line length character: No s

Das lag daran, dass ich vergessen hatte, das SCM-Tag in der Datei pom.xml meines Maven-Projekts anzugeben, und verwendete stattdessen die SCM-Informationen aus dem übergeordneten Projekt .. __ in GitLab.

Die Lösung für mich war, die Env-Variable GIT_SSH zu deaktivieren, die auf PuTTY (plink.exe) verweist.

Ich füge meine Erfahrung dieser langen Liste möglicher Lösungen hinzu.

In meinem Fall hatte ich Zugriff auf das Repo, das ich geklont hatte, aber keinen Zugriff auf andere interne Repos, auf die package.json als Abhängigkeiten oder DevDependencies hinweist. Die Lösung erhielt also Zugriff auf diese Repos.

Meine Lösung unter Windows bestand darin, die Verbindung zu SSH in .git/config zu ändern:

[remote "Origin"] url = [email protected]:

Wie hier beschrieben:

https://help.github.com/de/articles/changing-a-remotes-url

Ich fügte nur eine mögliche Lösung für andere in meiner Situation hinzu ... In meinem Fall versuchte ich, ein Tag zu verschieben. 

git Push heroku MYTAG:master

Erst als ich das Tag dereferenzierte, funktionierte es

git Push heroku MYTAG^{}:master

Mehr darüber erfahren Sie hier: Was bedeutet ^ {} in git?

<rev>^{}, e.g. v0.99.8^{}

Ein Suffix ^ gefolgt von einem leeren Klammerpaar bedeutet, dass das Objekt ein Tag sein und das Tag rekursiv dereferenzieren kann, bis ein Nicht-Tag-Objekt gefunden wird.