Los resultados de inserción de Git son fatales: error de protocolo: carácter de longitud de línea incorrecta: este

Estoy intentando que GitLab funcione en mi server (ejecutando CentOS 6.5). Seguí la receta de gitlab a la línea, pero no puedo hacer que funcione. Puedo acceder a la interfaz web, crear nuevos proyectos pero presionar a la twig principal devuelve el siguiente error:

fatal: protocol error: bad line length character: This 

He realizado comprobaciones en el entorno de producción, aquí están los resultados:

 Checking Environment ... Git configunetworking 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 networkingis-cli executable: networkingis-cli 2.4.10 Send ping to networkingis 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 

Para el error de script de inicio, el recibo dice

No te preocupes por ese error si estás seguro de que has descargado la actualización

así que al download la última, no puedo hacer mucho al respecto.

Me he estado golpeando la cabeza la semana pasada, y no puedo entender por qué ocurre este error, ¡cualquier ayuda sería apreciada!

Si alguien más tiene este problema, la solución es cambiar el shell de inicio de session del usuario 'git' (o como se llame su usuario) a /bin/bash . Esto se puede hacer a través del command: usermod -s /bin/bash git ( Link ). La razón para cambiar el shell de inicio de session es porque el shell pnetworkingeterminado para el usuario git es /sbin/nologin (o similar, dependiendo del entorno), lo que impide que la aplicación git inicie session como el usuario git en el server git.

Solo para reference de otros usuarios:

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

Como en mi caso, este tipo de error puede solucionarse agregando usuarios (incluso usted) al proyecto en gitlab:

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

Además, asegúrese de que su key pública esté configurada en su Profile settings > SSH Key or in Project > Settings > Deploy Keys usuario Profile settings > SSH Key or in Project > Settings > Deploy Keys

https://gitlab.com/profile/keys

Otra cosa que debes verificar es que tu .bashrc no imprime material extra. Por ejemplo, "echo" hello "" en .bashrc crea el error:

 [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 

Tenga en count que decir hola causó un gran problema.

Eliminar el 'echo' hello '' de mi .bashrc permite que git funcione como se espera de nuevo. Es posible que necesite "> & / dev / null" para eliminar la salida si su .bashrc hace cosas más complicadas.

La solución a mi problema con esto fue que había olvidado agregar una key de implementación para el proyecto (para el usuario que estaba tratando de implementar).

Agregar una key de implementación en https: // gitlab / group / project / deploy_keys me solucionó.

Otra posibilidad es que haya escrito mal el nombre del repository.

Lo he hecho dos veces en los últimos dos días. Agregué un control remoto y lo escribí mal y escribí mal el nombre al crear el proyecto en GitLab.

En ambos casos, cuando traté de empujar a control remoto, obtuve

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

¡Así que revisa la ortografía!

Además, si crea el proyecto con un nombre diferente (como un grupo), asegúrese de que sea el control remoto que agregue.

Puede get el post de error real haciendo:

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

De acuerdo con este protocolo, git documentation git espera al comienzo de cada línea su tamaño y luego el contenido. Parece que GitLab no hace eso y envía el post de error directamente.

Experimenté este post de error hoy ("No s"), y en realidad tenía que ver con que no tenía derecho a acceder al repository de destino. Aunque el post de error es muy extraño, esto podría ayudar a las personas a seguir trabajando.

Usamos Gitlab.

 sudo gitlab-ctl reconfigure 

y entonces

 sudo gitlab-ctl restart 

debería hacer el truco

En mi caso (key privada sobre ~ / .ssh / config) tuve que omitir la parte ssh en:

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

Funcionó con:

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

El post de error fue:

fatal: error de protocolo: carácter de longitud de línea incorrecta: No s

En mi caso, mi nombre de usuario fue cambiado y la configuration de git de este repository no se actualizó para que coincida con el nuevo nombre.

Verifica tus controles remotos de git para asegurarte de que están apuntando al lugar correcto:

git remote -v

Actualice la configuration editando la configuration manualmente:

vim .git/config

o a través de commands

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

Agregando mi experiencia a esta larga list de posibles soluciones.

En mi caso, tuve acceso al repository que cloné, pero no acceso a otros repos internos, el package.json se refería json como dependencies o devDependencias. Entonces, la solución también fue acceder a estos repositorys.

Tuve el mismo problema y resultó que estaba trabajando en una sucursal de Git. Todo lo que tenía que hacer era presionar al maestro.

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

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

Esto fue causado porque olvidé especificar la label SCM en el pom.xml de mi proyecto Maven, por lo que usó la información SCM del proyecto padre en su lugar. También tuve que agregar a nuestro usuario de Jenkins al proyecto en GitLab.

Espero que esto pueda ayudar a alguien 🙂

cambiar el caparazón de git

 usermod -s /usr/bin/git-shell git 

Solo agrego una posible solución a otros en mi situación. En mi caso, estaba tratando de empujar una label.

 git push heroku MYTAG:master 

No fue hasta que desreferencié la label que funcionó

 git push heroku MYTAG^{}:master 

Puedes leer más sobre esto aquí: ¿Qué significa ^ {} en git?

<rev>^{}, eg v0.99.8^{}

Un sufijo ^ seguido de un par de llaves vacías significa que el object podría ser una label, y desreferencer la label recursivamente hasta que se encuentre un object que no sea label.

Cuando quería presionar mis commits, recibí este error: fatal: error de protocolo: carácter de longitud de línea incorrecta: No s

Lo resolví solo con una comprobación de connection ssh: ssh git @ hostIp

La solución para mí fue desarmar la variable de env GIT_SSH que apuntaba a putty (plink.exe)

Tenía el mismo problema, en mi caso el repository de origen se había movido, cambiar .git / config resolvió mi problema.