Résultats Git Push fatals: erreur de protocole: caractère de longueur de ligne incorrect: This
J'essaie de faire fonctionner GitLab sur mon serveur (avec CentOS 6.5). J'ai suivi le gitlab-receipe jusqu'à la ligne, mais je n'arrive pas à le faire fonctionner. Je suis en mesure d'accéder à l'interface Web, de créer de nouveaux projets, mais le fait d'appuyer sur la branche principale renvoie l'erreur suivante:
fatal: protocol error: bad line length character: This
J'ai effectué des vérifications sur l'environnement de production, voici les résultats:
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
Pour l'erreur de script d'initialisation, le reçu indique
Ne vous inquiétez pas de cette erreur si vous êtes sûr d’avoir téléchargé la mise à jour
donc, comme j'ai téléchargé le dernier, je ne peux pas vraiment faire grand chose à ce sujet.
Je me suis cogné la tête depuis une semaine et je ne peux pas comprendre pourquoi cette erreur se produit. Toute aide serait appréciée!
Si quelqu'un d'autre a ce problème, la solution consiste à changer le shell de connexion de l'utilisateur 'git' (ou le nom de votre utilisateur) en /bin/bash. Cela peut être fait via la commande: usermod -s /bin/bash git ( Link ). La raison pour laquelle le shell de connexion a été modifié est que le shell par défaut pour l'utilisateur git est /sbin/nologin (ou similaire, selon l'environnement), ce qui empêche l'application git de se connecter en tant qu'utilisateur git sur le serveur git.
Juste pour la référence d'autres utilisateurs:
fatal: protocol error: bad line length character: no s
can be a truncated answer for "No such project".
Comme dans mon cas, ce genre d'erreur peut être corrigé en ajoutant un utilisateur (même vous-même) au projet dans gitlab:
https://gitlab.com/username/your_project/project_members
assurez-vous également que votre clé publique est définie dans votre utilisateur Profile settings > SSH Key or in Project > Settings > Deploy Keys
Une autre chose à vérifier est que votre .bashrc n'imprime pas de choses supplémentaires . Par exemple 'echo "hello"' dans .bashrc crée l'erreur:
kruus@borg:~/malt$ ssh snake01
Last login: Tue Oct 21 10:44:31 2014 from 138.15.166.103
hello
...
kruus@snake01:/net/snake01/usr/hydra/kruus/malt$ git pull
fatal: protocol error: bad line length character: hell
Notez comment dire bonjour a causé un sacré problème.
Le retrait de 'echo "hello"' de mon .bashrc permet à git de fonctionner à nouveau comme prévu. Vous aurez peut-être besoin de "> &/dev/null" pour supprimer la sortie si votre .bashrc fait des choses plus compliquées.
Une autre possibilité est que vous avez mal orthographié le nom du référentiel.
Je l'ai fait deux fois ces deux derniers jours. J'ai ajouté une télécommande, mal orthographiée et mal orthographiée lors de la création du projet sur GitLab.
Dans les deux cas, lorsque j’ai essayé d’appuyer sur Remote, j’ai eu
fatal: protocol error: bad line length character: No s
Alors vérifiez cette orthographe!
De même, si vous créez le projet sous un nom différent (comme un groupe), assurez-vous que c'est la télécommande que vous ajoutez.
Vous pouvez obtenir le message d'erreur en procédant comme suit:
ssh [email protected] "git-upload-pack yournamespace/yourreponame.git"
Selon cette documentation git , le protocole git attend au début de chaque ligne sa taille puis son contenu. On dirait que GitLab ne le fait pas et envoie directement le message d'erreur.
La solution à mon problème avec ceci était que j'avais oublié d'ajouter une clé de déploiement pour le projet (pour l'utilisateur que je tentais de déployer en tant que).
L'ajout d'une clé de déploiement dans https: // gitlab/group/project/deploy_keys m'a résolu.
J'ai rencontré ce message d'erreur aujourd'hui ("No s"), ce qui était dû au fait que je n'avais aucun droit sur Push vers le référentiel cible. Même si le message d'erreur est très étrange, cela pourrait aider les gens à continuer à travailler.
Nous utilisons Gitlab.
Sudo gitlab-ctl reconfigure
et alors
Sudo gitlab-ctl restart
devrait faire l'affaire
Dans mon cas, mon nom d'utilisateur a été changé et la configuration git de ce référentiel n'a pas été mise à jour pour correspondre au nouveau nom.
Vérifiez vos télécommandes git pour vous assurer qu'elles pointent au bon endroit:
git remote -v
Mettez à jour la configuration en la modifiant manuellement:
vim .git/config
ou par commandes
git remote set-url Origin https://github.com/USERNAME/OTHERREPOSITORY.git
Dans mon cas (clé privée sur ~/.ssh/config) je devais laisser de côté la partie ssh dans:
git clone ssh://git@hostname:username/repository.git
Cela a fonctionné avec:
git clone git@hostname:username/repository.git
Le message d'erreur était:
fatal: erreur de protocole: caractère de longueur de ligne incorrect: aucun s
changer la coquille de git
usermod -s /usr/bin/git-Shell git
J'ai eu le même problème et il s'est avéré que je travaillais sur une branche git. Tout ce que j'avais à faire, c'était Push to the master.
$ git Push <remote> <local branch name>:<remote branch to Push into>
Si le même problème se présentait, dans mon cas, le référentiel Origin avait été déplacé. Changer le fichier .git/config avait résolu mon problème.
Dans mon cas, j'observais cette erreur uniquement dans "Extensions SSH" pour Windows.
La même commande a fonctionné à partir de la ligne de commande. J'ai changé le paramètre SSH de PuTTY à OpenSSH et le système a cessé de générer des erreurs.
Dans mon cas, cette erreur a été corrigée en modifiant le shell distant git-user en git-Shell en utilisant chsh:
chsh -s $(command -v git-Shell) git
git-Shell officiel { documentation } _. Pour des raisons de sécurité, il est vivement recommandé d'utiliser ce shell pour git-user sur un serveur de référentiel distant.
Quand j'ai voulu pousser mes commits, j'ai eu cette erreur:
fatal: protocol error: bad line length character: No s
J'ai résolu ceci simplement par un contrôle de connexion SSH:
ssh Git@hostIp
Mon erreur était: fatal: protocol error: bad line length character: No s
Cela est dû au fait que j'ai oublié de spécifier le tag SCM dans le fichier pom.xml de mon projet Maven, il a donc utilisé les informations SCM du projet parent à la place . J'ai également dû ajouter notre utilisateur Jenkins au projet. dans GitLab.
La solution pour moi était de supprimer la variable env GIT_SSH qui pointait vers PuTTY (plink.exe)
Ajouter mon expérience à cette liste déjà longue de solutions possibles.
Dans mon cas, j'avais accès au référentiel que j'avais cloné, mais aucun accès à un autre référentiel interne que le package.json désignait par dépendances ou devDependencies…. La solution obtenait donc également l'accès à ces référentiels.
Juste en ajoutant une solution possible aux autres dans ma situation… .. Dans mon cas, j'essayais de pousser un tag.
git Push heroku MYTAG:master
Ce n'est que lorsque j'ai déréférencé l'étiquette que cela a fonctionné
git Push heroku MYTAG^{}:master
Vous pouvez en lire plus à ce sujet ici: Que signifie ^ {} dans git?
<rev>^{}, e.g. v0.99.8^{}Un suffixe ^ suivi d'une paire d'accolades vide signifie que l'objet peut être une balise et déréférence la balise de manière récursive jusqu'à ce qu'un objet non-tag soit trouvé.