Errore di clone gitolite git

Sto provando a installare gitolite sul mio server (server Macos).

Ho seguito le istruzioni nel documento INSTALL trovato qui: http://sitaramc.github.com/gitolite/doc/1-INSTALL.html

Ho installato il metodo di root.

Ho ottenuto tutto il setup (autenticazione ssh pubkey e impostazione predefinita gitolite)

$ssh [email protected] info hello admin, the gitolite version here is v1.5.9.1-27-gb97115f the gitolite config gives you the following access: RW gitolite-admin @R_ @W_ testing 

Secondo le istruzioni di installazione dovrei essere in grado di eseguire il checkout di un repository.

Ma quando provo a clonare il repository gitolite-admin ottengo un errore:

 $ git clone [email protected]:gitolite-admin Cloning into gitolite-admin... Assertion failed: (argv0_path), function system_path, file exec_cmd.c, line 27. error: git-shell died of signal 6 fatal: The remote end hung up unexpectedly 

Ho l’ultima versione git di gitolite e git v. 1.7.3.4

Qualcuno può aiutarmi?

Modifica 1: aggiunto il comando clone git prima del messaggio di errore

Sembra che la correzione corretta a questo errore sia da aggiungere

 $ENV{GIT_EXEC_PATH} = "/usr/libexec/git-core"; 

al tuo file .gitolite.rc.

L’ OP skipper3k segnala un problema con RUNTIME_PREFIX in Git, un po ‘simile alla domanda ” git pull broken “:

Non sono sicuro che RUNTIME_PREFIX sia definito per te. Ma mentre si annidava nel Makefile , ho notato che il prefisso predefinito era $(HOME) . Sospetto che questa possa essere la causa dei tuoi problemi.

La semplice risposta è metterla in ~/.bashrc :

 export GIT_EXEC_PATH=/opt/local/libexec/git-core 

Se vuoi saperne di più su cosa sta succedendo, probabilmente dovrai ricompilare git usando port -d upgrade -f git-core (o simile) e guarda attentamente il log di build per vedere dove viene impostato il prefisso.
Per inciso, port cat git-core mostra un uso pesante di ${prefix} .


Risposta originale:

In primo luogo, hai ricevuto la versione gitolite più aggiornata?
Alla pagina https://github.com/sitaramc/gitolite/ , è necessario considerare il ramo ” pu “.

La documentazione di installazione è quindi questa .


GitoliteV3 o ‘g3’ doc:

“Installazione” comprende le seguenti opzioni:

  1. Mantieni le sorgenti ovunque e utilizza il percorso completo per eseguire il comando gitolite.
  2. Mantieni le fonti ovunque e collega semplicemente il programma gitolite ad una directory sul tuo $ PATH.
  3. Copia i sorgenti da qualche parte e usa quel percorso per eseguire il comando gitolite.

Puoi eseguire il comando “Installa” in 3 modi diversi:

 # option 1 gitolite/install # option 2 gitolite/install -ln # defaults to $HOME/bin, or use a specific directory: gitolite/install -ln /usr/local/bin # option 3 gitolite/install -to /usr/local/gitolite/bin 

Vecchia risposta per la gitolite V2: in secondo luogo, preferisco il metodo from-client metodo:

Il vantaggio di questo metodo è che ti costringe a risolvere il problema ssh pubkey prima di tentare l’installazione.
Funziona meglio se hai userid dedicati,

  • uno sul server per l’installazione di gitolite,
  • e uno sul client per amministrarlo.

Lo svantaggio è che l’utente amministratore finisce con due chiavi

  • uno per l’accesso alla shell (che ha iniziato con) e
  • uno per l’accesso gitolite (che lo script crea se necessario).

Quindi mi piace creare un file ~/.ssh/config con i due diversi set di parametri:

 host gitolite user git hostname server identityfile ~/.ssh/git host gitadmin user git hostname server identityfile ~/.ssh/id_rsa (myaccount public key) 

L’ amministratore gitolite è visibile solo per la prima chiave pubblica ssh:

 C:\HOMEWARE\git>ssh gitolite hello git, the gitolite version here is v1.5.9-25-ga10287a the gitolite config gives you the following access: RW gitolite-admin @R_ @W_ testing Connection to server closed. 

Con il mio account:

 C:\HOMEWARE\git>ssh gitadmin hello myaccount, the gitolite version here is v1.5.9-25-ga10287a the gitolite config gives you the following access: @R_ @W_ testing Connection to mccprdgit10 closed. 

Così:

 C:\HOMEWARE\git>git clone gitolite:gitolite-admin Cloning into gitolite-admin... remote: Counting objects: 16, done. remote: Compressing objects: 100% (13/13), done. remote: Total 16 (delta 2), reused 0 (delta 0) Receiving objects: 100% (16/16), done. Resolving deltas: 100% (2/2), done. 

Il problema era con il modo in cui git è stato compilato su mac. Ho dovuto compilare manualmente git senza il set RUNTIME_PREFIX. Ora funziona.

Ho praticamente provato tutto quello che potevo pensare e non riuscivo a farlo funzionare … finché non ho notato da qualche parte che GIT è molto alto sugli indirizzi email … quindi ho rigenerato la mia coppia di chiavi ssh usando l’opzione -C:

ssh-keygen -t rsa -C ” [email protected]

Basso ed ecco, all’improvviso ho potuto clonare gitolite-admin senza alcun problema.

Apparentemente l’e-mail nella chiave user.email di .gitconfig DEVE corrispondere all’e-mail che è stata utilizzata per generare la chiave SSH. Onestamente, se nella tua cartella .ssh hai solo 1 coppia di chiavi, perché mai importa che l’email corrisponda? Imho, se si passa una chiave e la chiave è in authorized_keys sul server, dovrebbe funzionare indipendentemente dalla proprietà .gitconfig user.email.

non so esattamente quale sia il problema con la tua installazione, sarebbe utile sapere quali comandi hai eseguito per installare gitolite sul tuo server.

Vi consiglio di leggere questi due link, sono stati utili per me quando ho installato gitolite:

http://kris.me.uk/2010/09/30/git-repository-server-gitolite.html (specialmente questo)

http://progit.org/book/ch4-8.html

Avendo appena affrontato questo per la terza volta dopo aver dimenticato le prime due volte, immagino che non possa essere inusuale.

 $ git clone [email protected]:gitolite-admin Cloning into gitolite-admin... fatal: The remote end hung up unexpectedly 

Almeno una ragione per questo è che l’utente gitolite deve avere una shell di login – fare in modo che un utente del sistema non funzioni per qualche motivo .. cade semplicemente sopra, causando l’errore sopra.

Inoltre, per il test ssh, devi distriggersre i PTY sulla riga di comando altrimenti ssh semplicemente non funzionerà – penso che forse ha funzionato con le versioni precedenti di ssh ma non su tutto ciò che ho:

 $ ssh [email protected] PTY allocation request failed on channel 0 $ ssh -T [email protected] hello key, this is [email protected] running gitolite3 v3.01-10-g699bafa on git 1.7.10 

(Perché pensa che io sia chiamato ‘chiave’ è un altro problema di configurazione che non ho ancora risolto).

Come soluzione per Gitolite v3, per Mac Lion, questo è ciò che ha funzionato per me:

$ ENV {PATH} = “/ usr / local / bin: $ ENV {PATH}”;

Aggiungilo a ~ / .gitolite.rc per l’ utente git sul server . Assicurati che sia prima del “1”; alla fine.

Come descritto in: https://serverfault.com/questions/307493/cant-clone-gitolite-admin

Le soluzioni che coinvolgono GIT_PATH sono superate, secondo: http://sitaramc.github.com/gitolite/g2migr.html