it-swarm.com.de

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

Ich versuche GitLab auf meinem Server zum Laufen zu bringen (mit CentOS 6.5). Ich bin dem gitlab-receipe bis zur Zeile gefolgt, aber ich bekomme es einfach nicht. Ich bin in der Lage, auf die Webschnittstelle zuzugreifen und neue Projekte zu erstellen. Wenn Sie jedoch in den Master-Zweig wechseln, wird der folgende Fehler angezeigt: 

fatal: protocol error: bad line length character: This

Ich habe die Produktionsumgebung überprüft, hier sind die Ergebnisse: 

Checking Environment ...

Git configured for git user? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
update hook up-to-date? ... yes
update hooks in repos are links: ... 
ASC / Wiki ... repository is empty
Running /home/git/gitlab-Shell/bin/check
Check GitLab API access: OK
Check directories and files: 
    /home/git/repositories: OK
    /home/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.4.10
Send ping to redis server: PONG
gitlab-Shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... no
  Try fixing it:
  Redownload the init script
  For more information see:
  doc/install/installation.md in section "Install Init Script"
  Please fix the error above and rerun the checks.
projects have namespace: ... 
ASC / Wiki ... yes
Projects have satellites? ... 
ASC / Wiki ... can't create, repository is empty
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.3)

Checking GitLab ... Finished

Für den Init-Skriptfehler heißt es in der Quittung 

Machen Sie sich nichts aus dem Fehler, wenn Sie sicher sind, dass Sie .__ heruntergeladen haben. das aktuellste

da ich die neueste Version heruntergeladen habe, kann ich nicht viel dagegen tun.

Ich habe in der letzten Woche meinen Kopf geschlagen und kann nicht herausfinden, warum dieser Fehler auftritt. Jede Hilfe wäre dankbar !!

37
user3404044

Wenn jemand anderes dieses Problem hat, besteht die Lösung darin, die Login-Shell des Benutzers 'git' (oder wie auch immer Ihr Benutzer aufgerufen wird) in /bin/bash zu ändern. Dies kann über den Befehl erfolgen: usermod -s /bin/bash git ( Link ). Der Grund für die Änderung der Anmelde-Shell liegt darin, dass die Standard-Shell für den git-Benutzer /sbin/nologin (oder je nach Umgebung) ähnlich ist. Dies verhindert, dass sich die git-Anwendung als git-Benutzer auf dem git-Server anmeldet.

33
Argilium

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

20
einverne

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.

12
Erik Kruus

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.

4
dsc

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. 

4
Borja Aparicio

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 .

4
Gavin Gilmour

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.

2
sjorsvb
Sudo gitlab-ctl reconfigure

und dann

Sudo gitlab-ctl restart

sollte den Trick tun

2
mytydev

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

1
Chase Coney

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

1
hellcode

Ändern Sie die Shell von Git

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

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>
0
virulant

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

0
Rui Moreira

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.

0
Sergei G

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.

0

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]
0
HoGiggle

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.

0
Stephanie

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

0
franssu

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.

0
Nobita

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

0
Dreamfish

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.

0
sebastianr