Git spinge i risultati in modo fatale: errore di protocollo: carattere di lunghezza della linea sbagliata: Questo

Sto cercando di far funzionare GitLab sul mio server (con CentOS 6.5 in esecuzione). Ho seguito la gitlab-receipe sulla linea, ma non riesco a farlo funzionare. Sono in grado di accedere all’interfaccia web, creare nuovi progetti, ma il push al ramo master restituisce il seguente errore:

fatal: protocol error: bad line length character: This 

Ho fatto dei controlli sull’ambiente di produzione, ecco i risultati:

 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 

Per l’errore di script init, la ricevuta dice

Non preoccuparti di questo errore se sei sicuro di aver scaricato l’aggiornamento

così come ho scaricato l’ultimo, non posso davvero fare molto.

Ho battuto la testa per la scorsa settimana, e non riesco a capire perché questo errore si sta verificando, ogni aiuto sarebbe apprezzato !!

Se qualcun altro ha questo problema, la soluzione è di cambiare la shell di login dell’utente ‘git’ (o qualunque sia il nome dell’utente) in /bin/bash . Questo può essere fatto tramite il comando: usermod -s /bin/bash git ( Link ). La ragione per cambiare la shell di login è perché la shell di default per l’utente git è /sbin/nologin (o simile, a seconda dell’ambiente), che impedisce all’applicazione git di accedere come utente git sul server git.

Solo per altri utenti di riferimento:

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

Come nel mio caso, questo tipo di errore può essere risolto aggiungendo l’utente (anche se stesso) al progetto in gitlab:

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

Inoltre, assicurati che la tua chiave pubblica sia impostata nelle Profile settings > SSH Key or in Project > Settings > Deploy Keys utente Profile settings > SSH Key or in Project > Settings > Deploy Keys

https://gitlab.com/profile/keys

Un’altra cosa da controllare è che il tuo .bashrc non stampa cose extra. Ad esempio “echo” ciao “” in .bashrc crea l’errore:

 [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 

Nota come dire ciao ha causato un inferno di problemi.

La rimozione di “echo” ciao “” dal mio .bashrc consente a git di funzionare come previsto di nuovo. Potrebbe essere necessario “> & / dev / null” per rimuovere l’output se il tuo .bashrc fa cose più complicate.

La soluzione al mio problema era che avevo dimenticato di aggiungere una chiave di deploy per il progetto (per l’utente che stavo cercando di implementare come).

L’aggiunta di una chiave di distribuzione in https: // gitlab / group / project / deploy_keys ha risolto il problema .

Un’altra possibilità è che hai sbagliato a digitare il nome del repository.

L’ho fatto due volte negli ultimi due giorni. Ho aggiunto un telecomando e l’ho scritto male e ho sbagliato a digitare il nome durante la creazione del progetto su GitLab.

In entrambi i casi, quando ho provato a spingere al telecomando, ho ottenuto

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

Quindi controlla l’ortografia!

Inoltre, se crei il progetto con un nome diverso (come un gruppo), assicurati che sia il telecomando che aggiungi.

È ansible ottenere il messaggio di errore effettivo facendo:

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

Secondo questa documentazione git, il protocollo git prevede all’inizio di ogni riga le sue dimensioni e quindi il contenuto. Sembra che GitLab non lo faccia e invia direttamente il messaggio di errore.

Ho avuto questo messaggio di errore oggi (“No s”), e in realtà ha avuto a che fare con me che non ha i diritti di spingere verso il repository di destinazione. Anche se il messaggio di errore è molto strano, questo potrebbe aiutare le persone a continuare a lavorare.

Usiamo Gitlab.

 sudo gitlab-ctl reconfigure 

e poi

 sudo gitlab-ctl restart 

dovrebbe fare il trucco

Nel mio caso (chiave privata su ~ / .ssh / config) ho dovuto lasciare la parte ssh in:

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

Ha funzionato con:

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

Messaggio di errore era:

fatale: errore di protocollo: carattere di lunghezza della linea errata: No s

Nel mio caso, il mio nome utente è stato modificato e git config di questo repository non è stato aggiornato per corrispondere al nuovo nome.

Controlla i telecomandi git per assicurarti che puntino al posto corretto:

git remote -v

Aggiorna la configurazione modificando manualmente la configurazione:

vim .git/config

o tramite i comandi

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

Aggiungendo la mia esperienza a questo già lungo elenco di possibili soluzioni.

Nel mio caso ho avuto accesso al repository clonato, ma non ho avuto accesso ad altri repository interni a cui package.json si riferiva come dipendenze o devDependencies. Quindi la soluzione stava ottenendo anche l’accesso a questi repository.

Ho avuto questo stesso problema e ho scoperto che stavo lavorando su un ramo git. Tutto quello che dovevo fare era spingere al maestro.

 $ git push  : 

Il mio errore è stato: fatal: protocol error: bad line length character: No s

Ciò è stato causato dal fatto che ho dimenticato di specificare il tag SCM nel pom.xml del mio progetto Maven, quindi ha usato le informazioni SCM dal progetto principale. Ho anche dovuto aggiungere il nostro utente Jenkins al progetto in GitLab.

Spero che questo possa aiutare qualcuno 🙂

cambia il guscio di git

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

Aggiungendo solo una ansible soluzione ad altri nella mia situazione. Nel mio caso stavo cercando di spingere un tag.

 git push heroku MYTAG:master 

Non è stato fino a quando ho cancellato il tag che ha funzionato

 git push heroku MYTAG^{}:master 

Puoi leggere di più a riguardo qui: cosa significa ^ {} in git?

^{}, eg v0.99.8^{}

Un suffisso ^ seguito da una coppia di parentesi graffe vuota significa che l’object potrebbe essere un tag e dereferenziare il tag in modo ricorsivo finché non viene trovato un object non tag.

Quando volevo spingere i miei commit, ho ricevuto questo errore: fatale: errore di protocollo: carattere di lunghezza della linea errata: No s

Ho risolto questo solo con un controllo della connessione ssh: ssh git @ hostIp

La soluzione per me era di disinserire la variabile ENV GIT_SSH che stava puntando a putty (plink.exe)

Ho avuto lo stesso problema, nel mio caso il repository di origine era stato spostato, cambiando .git / config risolto il mio problema.