Differences between revisions 32 and 34 (spanning 2 versions)
Revision 32 as of 2015-12-11 09:02:01
Size: 19961
Comment: Update for tracker.debian.org
Revision 34 as of 2015-12-28 19:13:11
Size: 20232
Comment: sync with English master
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
~-[[DebianWiki/EditorGuide#translation|Traduzioni]]: [[Alioth/Git|English]] - Italiano-~ ~-[[DebianWiki/EditorGuide#translation|Traduzioni]]: [[de/Alioth/Git|Deutsch]] - [[Alioth/Git|English]] - Italiano-~
Line 111: Line 111:
$ git config --add multimailhook.mailinglist "project-commit@lists.alioth.debian.org" $ git config --add multimailhook.mailinglist "<progetto>-commit@lists.alioth.debian.org"
Line 124: Line 124:
Notare che se il repository git ha lo stesso nome del pacchetto sorgente, è sufficiente inviare le notifiche di commit a dispatch@tracker.debian.org invece di usare la forma espansa {{{dispatch+<pacchetto_sorgente>@tracker.debian.org}}}.
Line 130: Line 132:
Ci sono alcuni aggiornarementi importanti in https://git.hadrons.org/cgit/debian/git-hooks.git che sono già stati inviati agli amministratori di Alioth. Ci sono alcuni aggiornamenti importanti in https://git.hadrons.org/cgit/debian/git-hooks.git che sono già stati inviati agli amministratori di Alioth.

Traduzioni: ?Deutsch - ?English - Italiano


Usare Git su Alioth

Creare un repository

Progetto di manutenzione collaborativa

Invece di registrare progetti separati per i pacchetti è consigliabile utilizzare il progetto di manutenzione collaborativa, per maggiori informazioni si veda la pagina del ?progetto di pacchettizzazione. Una volta concesso l'accesso a tale progetto (gli sviluppatori Debian hanno accesso in modo predefinito, mentre gli altri devono fare richiesta) è possibile avviare immediatamente il progetto Git ospitato. Il modo più semplice per farlo è eseguire il comando create-remote-repo da git-buildpackage dal proprio repository di sviluppo locale:

$ gbp create-remote-repo

(Notare che attualmente ciò non imposta gli hook in modo corretto.)

Un metodo alternativo è quello di accedere in git.debian.org e creare un repository git in /git/collab-maint/. Si può usare un piccolo script su git.debian.org:

   1 #!/bin/bash
   2 set -u
   3 umask 002
   4 cd /git/collab-maint && ./setup-repository $1 "Packaging for $1"
   5 echo -e "\n: Clonare questo repository usando: git clone ssh://$USER@git.debian.org/git/collab-maint/$1.git"
   6 echo "Oppure aggiungere il remoto ad un repository esistente: git remote add origin ssh://$USER@git.debian.org/git/collab-maint/$1.git"

Creando un repository con il simbolo dell'addizione nel nome (ad es "dvd+rw-tools") gitweb richiederà di sostituire il "+" contenuto nell'URL con "%2B", per visualizzare il repository git l'indirizzo sarà quindi "https://anonscm.debian.org/gitweb/?p=collab-maint/dvd%2Brw-tools.git;a=summary".

Progetto separato

Per i progetti registrati separatamente Alioth creerà un repository chiamato /git/<gruppo-progetto> di proprietà del proprio gruppo di progetto (a condizione che si sia selezionato Git come tipo di repository desiderato, vedere la ?sezione dedicata nelle FAQ). cgit invece non ha questo problema.

È possibile invece creare molteplici repository in questa directory:

$ # On git.debian.org via SSH
$ umask 002
$ mkdir <progetto>.git
$ cd <progetto>.git
$ git --bare init --shared
$ vim description
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

Caricamento iniziale

È possibile farlo manualmente come descritto qui o utilizzare git-buildpackage, come descritto alla pagina http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM

Quindi inserire un contenuto in tale repository, usando git fetch/pull su git.debian.org o git push su git.debian.org da una macchina remota. Vedere sotto per gli URL Git utilizzabili.

<!> Esempio: creare un repository Git locale e inserirvi del codice sorgente esistente:

$ cd /percorso/del/codice/<progetto>
$ git init
$ git config user.name '<proprio_nome>'
$ git config user.email '<propria_email>'
$ git config gitweb.owner '<proprio_nome>'
$ git add .
$ git commit -m 'Importazione iniziale di <progetto> versione <versione>'
$ git tag <versione>

<!> Esempio: caricare un progetto su un repository collab-maint in Alioth:

$ cd /percorso/del/<progetto>.git
$ git remote add alioth ssh://<utente>@git.debian.org/git/collab-maint/<progetto>.git
$ git push alioth <nome_ramo>
$ git push alioth --tags

Accesso ai repository

Sono acceessibili da git usando sftp, rsync tramite ssh o git-server/http per l'accesso in sola lettura. Si noti che https://anonscm.debian.org/cgit/ viene aggiornato solamente ogni sei ore da cron, perciò ci vuole un po' di pazienza quando si crea un nuovo repository... alla fine apparirà. Per esempio, si potrà fare il check out del proprio ramo tramite sftp con:

$ git clone ssh://<utente>@git.debian.org/git/<gruppo>/<progetto>.git

Gli utenti anonimi potranno beneficiare di un accesso in sola lettura con i seguenti comandi; <gruppo> potrebbe ad esempio essere il nome del pacchetto o, se ospitato in collaborazione, collab-maint.

$ git clone git://anonscm.debian.org/git/<gruppo>/<progetto>.git
$ git clone https://anonscm.debian.org/git/<gruppo>/<progetto>.git

Usare il protocollo nativo git in quanto molto più efficiente che clonare via https/http, ma se il proprio firewall limita l'accesso alla porta 9418 allora lo si farà tramite https/http. Si noti che in questo modo sarà necessario scaricare nuovamente tutti gli oggetti se il repository su Alioth viene rimpacchettato.

Manutenzione del repository

I repository Git tendono a crescere piuttosto velocemente, di tanto in tanto bisogna comprimerli per risparmiare spazio e mantenere prestazioni ottimali (evitando di avere troppi file nella sottodirectory degli oggetti).

$ cd /git/<gruppo>/<progetto>.git
$ git repack && git gc

Tali operazioni dovrebbero essere sempre sicure (e possono essere eseguite tramite cron).

È possibile ottimizzare ancora di più con alcune opzioni, ma poi coloro che recuperano tramite https/http (pessima idea!) potrebbe avere problemi e non è sicuro eseguirle quando qualcun altro sta utilizzando il repository (per esempio caricando le nuove revisioni). Perciò questi comandi non vanno inseriti in un comando per cron:

$ git repack -a -d && git gc --prune

Impostazione delle notifiche

Invio email con diff

Modificare i valori pertinenti nelle righe seguenti:

$ cd <progetto>.git
# Per inviare diff ad una mailing list:
$ git config --add multimailhook.mailinglist "<progetto>-commit@lists.alioth.debian.org"
# Per inviare in aggiunta diff al PTS:
$ git config --add multimailhook.bcc "dispatch+<pacchetto_sorgente>@tracker.debian.org"
# Se non si ha una mailing-list per i commit e si vuole inviare il diff solo al PTS, è necessario usare il PTS come una mailing-list:
git config --add multimailhook.mailinglist "dispatch+<pacchetto_sorgente>@tracker.debian.org"
# Creare la notifica:
$ cat >hooks/post-receive <<END
#!/bin/sh
exec /usr/local/bin/git-commit-notice
END
$ chmod a+x hooks/post-receive

Notare che se il repository git ha lo stesso nome del pacchetto sorgente, è sufficiente inviare le notifiche di commit a dispatch@tracker.debian.org invece di usare la forma espansa dispatch+<pacchetto_sorgente>@tracker.debian.org.

Contrassegnare i bug chiusi come "pending" nel BTS

Per contrassegnare i bug chiusi nel debian/changelog come pending aggiungere /usr/local/bin/git-post-receive-tag-pending all'hook post-receive del repository, ad esempio:

exec pee /usr/local/bin/git-post-receive-tag-pending /usr/local/bin/git-commit-notice

Ci sono alcuni aggiornamenti importanti in https://git.hadrons.org/cgit/debian/git-hooks.git che sono già stati inviati agli amministratori di Alioth.

Invio notifiche su IRC tramite un bot KGB

kgb-client è installato su git.debian.org. Viene configurato usando una proprietà di configurazione di git, un file di configurazione che dovrebbe essere archiviato nello spazio dei file del proprio progetto su alioth e che viene eseguito come parte dell'hook post-receive

Mettere quanto segue in hooks/post-receive:

exec /home/groups/kgb/bin/kgb-client-trunk

e assicurarsi di configurarlo con:

git config kgb.conf /home/groups/my-project/kgb-client.conf

Nel caso ci siano altri hook che devono essere eseguiti, lo standard input deve essere duplicato, come in:

exec pee /home/groups/kgb/bin/kgb-client-trunk /usr/local/bin/git-commit-notice

Per maggiori informazioni su come usare i bot KGB e avere l'accesso garantito per il proprio progetto, guardare la pagina di KGB su Alioth.

Uso di repository Git personali

Creazione di repository Git personali

È anche possibile avere repository Git personali. Accedere a git.debian.org, quindi:

$ mkdir ~/public_git
$ chmod a+xr public_git  # fornisce l'accesso al demone git
$ exit

Assumendo che $PRJ sia il nome del progetto, $PRJDIR il percorso del repository locale del progetto e 'login' il nome dell'utente su Alioth.

export PRJ=progetto                            # il nome del progetto esportato (es. 'pbuilder')
export PRJDIR=~/progetto                       # il percorso dell'attuale repository git locale
export login=nomeutente                        # il nome dell'utente su Alioth

Uscire dalla sessione per preparare il repository che sarà pubblicato, quindi copiare su Alioth.

git clone --bare $PRJDIR $PRJ.git              # crea la directory esportabile 
touch $PRJ.git/git-daemon-export-ok            # comunica al demone git che è un repository pubblico
cp $PRJ.git/hooks/post-update{.sample,}        # copia lo script hook
chmod a+x $PRJ.git/hooks/post-update           # prelevamento tramite https/http funzionante
(cd $PRJ.git && git update-server-info)        # prelevamento tramite https/http funzionante
editor $PRJ.git/description                    # modificare il file "description" per cgit/gitweb
scp -r $PRJ.git/ $login@git.debian.org:public_git/ # copia il repository su Alioth

Verificare che il repository sia visibile (può richiedere del tempo però, vedere sotto) accedendo con un browser:

https://anonscm.debian.org/cgit/users/$login/$PRJ.git/

Verificare che funzioni in una directory vuota temporanea:

$ git clone git://anonscm.debian.org/users/$login/$PRJ.git
# in alternativa si può usare il (lento) metodo di prelievo tramite https 
#git clone https://anonscm.debian.org/git/users/$login/$PRJ.git

Nota 1: rsync è molto più veloce di scp: rsync -av -e "ssh -l $login" $PRJ.git/ git.debian.org:public_git/$PRJ.git/

Nota 2: usare sshfs per creare il repository produce alcuni errori e pare più lento rispetto a creare il repository sul disco locale e quindi trasferirlo su Alioth con scp.

I collegamenti simbolici utilizzati per l'interfaccia cgit/gitweb vengono aggiornati ogni ora, al minuto 33 dell'ora.

Saranno disponibili tramite i seguenti URL:

$ git clone git://anonscm.debian.org/users/$login/$PRJ.git

Fare il fork di repository Git su Alioth

Esiste uno script che può fare il fork di un repository git pubblico e renderlo disponibile su Alioth per conto dell'utente. Esegue la maggior parte dei passi descritti nella sezione precedente. Studiarlo bene prima di usarlo. Lo si può usare in alioth con:

$ /srv/home/users/tpo/bin/clone_onto_alioth git://anonscm.debian.org/qualche/progetto_alioth.git

Mantenere aggiornati i repository Git pubblicati

L'upload sul repository si fa con:

$ git push ssh://$login@git.debian.org/~$login/public_git/$PRJ.git

Repository Git personali - il metodo morph

L'autore suppone di essere probabilmente il solo ad avere tale esigenza (da qui il 'metodo morph';) ), ma gli piacerebbe partire da zero, con un repository vuoto ed iniziare ad aggiungervi contenuti; ecco come fare.

Questo è un esempio reale che ha creato da questo documento, accedere a git.debian.org con il proprio utente quindi digitare:

$ mkdir ~/public_git
## fornisce l'accesso al demone git
$ chmod a+xr public_git
$ cd public_git
## crea la directory del progetto
$ git init --bare test.git
Inizializzato repository Git vuoto in /srv/alioth.debian.org/chroot/home/users/morph/public_git/test.git/
$ cd test.git/
$ cp hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
$ touch git-daemon-export-ok
$ git update-server-info
## imposta la descrizione del progetto
$ echo 'descrizione del progetto' > description

Il lavoro su Alioth è terminato, si può dare uno sguardo al repository vuoto all'indirizzo:

https://anonscm.debian.org/cgit/users/morph/test.git

Sulla propria macchina si può clonare il repository con:

$ git clone ssh://morph@git.debian.org/git/users/morph/test.git
Inizializzato repository Git vuoto in /home/morph/tmp/test/.git/
Attenzione: sembra sia stato clonato un repository vuoto.
Errore fatale: il sistema remoto è stato terminato inaspettatamente.

L'errore "fatale" è solo il modo con cui git dice che è stato clonato un repository vuoto.

È ora possibile iniziare a lavorare sul repository:

$ cd test
$ echo "file finto" > f
$ git add .
$ git commit -m "messaggio di commit"
[master (root-commit) 8ba3ab1] messaggio di commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 f
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 214 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://morph@git.debian.org/git/users/morph/test.git
 * [new branch]      master -> master

Ora che il nuovo ramo 'master' è configurato, si può usare normalmente git push senza dover specificare il repository e il riferimento. Anche cgit/gitweb ora mostrerà delle informazioni :)

Convertire un repository Alioth SVN in Git

Verrà ora fornita una sequenza di passi da seguire per convertire un repository SVN in uno Git (supponendo che siano entrambi su Alioth) analizzando l'esempio concreto della conversione del repository di reportbug. Memorizzare il suo URL in una variabile di shell, così che gli script di esempio siano più facilmente riutilizzabili per altri pacchetti.

SVN_URL='svn://svn.debian.org/svn/reportbug/'

In primo luogo è necessario riconfigurare il proprio progetto FusionForge per indicare che si desidera utilizzare git (si veda la ?sezione dedicata nelle FAQ) in modo che venga creato /git/<progetto>. Una volta fatto questo sarà possibile creare quanti repository git si desidera.

Riferimento: http://gitready.com/beginner/2009/02/04/converting-from-svn.html

Creare il file degli autori

SVN memorizza le informazioni sugli autori dei caricamenti come nome utente, mentre Git utilizza i nomi completi e gli indirizzi email.

Se si converte un repository senza un file autore i caricamenti apparterranno ad un utente fittizio nella forma di <SVN nomeutente>@<SVN UUID>, come restituito dal comando

$ svn info $SVN_URL| grep UUID
Repository UUID: 692dde74-6b68-4300-bcb1-27de2ae967a4

Al fine di creare un file completo dell'autore, c'è bisogno di sapere i nomi di tutti coloro che hanno caricato sul repository SVN, per farlo si può usare questo script:

$ svn log $SVN_URL | awk -F'|' '/^r[0-9]+/ { print $2 }' | sort -u
 appaji-guest
 bignose-guest
 lawrencc
 morph
 morph-guest
 (no author)
 root

Ora si può creare un file che contiene queste informazioni:

...
nome_utente_svn = nome_completo <indirizzo email>
...
morph = Sandro Tosi <morph@debian.org>
...

Questo stabilirà una corrispondenza tra i nomi utente SVN e quelli Git; modificare manualmente e memorizzare il file dove si preferisce per utilizzarlo in seguito; se si sta convertendo da un pacchetto manutenuto da un gruppo o da una serie di pacchetti potrebbe già esserci un file da poter utilizzare.

Si tenga presente che se il comando git svn clone trova un autore SVN che non è in questo file, terminerà con un errore e non porterà a termine la clonazione del repository.

Convertire il repository

Si è ora pronti per convertire il repository, verrà usato git-svn, un'ottima interfaccia bidirezionale tra SVN e Git (si può lavorare su Git e caricare su SVN, e recuperare il lavoro fatto su SVN).

Creare una directory per contenere il repository Git convertito (se non fosse corretto lo stesso nome <progetto> come è in SVN) e dunque fare l'effettiva conversione:

mkdir pkg
git svn clone $SVN_URL --prefix=svn-import/ --stdlayout --authors-file=<nomefile degli autori> --no-metadata pkg

Note:

  • è stato usato clone da git svn in quanto fa "init + fetch" in un singolo passaggio
  • è stato aggiunto un prefisso poiché questi rami verranno convertiti in seguito, ed un prefisso comune rende il tutto più semplice
  • --author-file specifica la posizione del file degli autori definito precedentemente
  • --no-metadata rimuoverà l'indirizzo SVN da ogni messaggio di upload (tipo "git-svn-id: svn://svn.debian.org/svn/pkg/trunk@696 692dde74-6b68-4300-bcb1-27de2ae967a4"); è stato usato con l'intenzione di rimuovere SVN, togliere l'opzione se si prevede di mantenere entrambi i repository
  • pkg/ è la directory di destinazione

Convertire le etichette e i rami remoti in quelli locali

Dopo la conversione le etichette SVN e i rami saranno tutti rami Git remoti, si potrebbe volerli convertire nelle corrette etichette Git e in etichette e rami locali.

Volendo firmare le etichette con la propria chiave GPG o PGP si aggiungerà l'opzione -s al comando git tag:

for branch in `git branch -r`; do
    if [ `echo $branch | egrep "svn-import/tags/.+$"` ]; then
        version=`basename $branch`
        subject=`git log -1 --pretty=format:"%s" $branch`
        GIT_COMMITTER_DATE=`git log -1 --pretty=format:"%ci" $branch` \
            git tag -f -m "$subject" "debian/$version" "$branch^"

        git branch -d -r $branch
    fi
done

Vengono elencati tutti i rami "tag/*", convertiti in etichette e rimossi i rami remoti.

Se si tratta di una migrazione a senso unico (SVN non verrà più usato), allora i riferimenti di compatibilità SVN possono essere rimossi:

git branch -d -r svn-import/trunk
git config --remove-section svn-remote.svn
rm -rf .git/svn .git/{logs/,}refs/remotes/svn/

Si convertono i restanti rami remoti in locali:

git config remote.origin.url .
git config --add remote.origin.fetch +refs/remotes/*:refs/heads/*
git fetch

Ed infine si può importare il sorgente a monte:

git symbolic-ref HEAD refs/heads/upstream
git rm --cached -r .
git commit --allow-empty -m 'initial upstream branch'
git checkout -f master
git merge upstream
git-import-orig ../foo_1.2.3.orig.tar.gz

Riferimenti:

Preparare il repository per la pubblicazione sul web

Quello ottenuto fino ad ora è un repository Git "iniettato" in una copia scaricata, lo si vorrà pubblicare sul web in modo che gli altri client lo possano clonare sulla propria macchina.

Si comincia con la creazione di un nuovo repository:

morph@alioth:~/reportbug$ git clone --bare reportbug reportbug.git
Initialized empty Git repository in /srv/alioth.debian.org/chroot/home/users/morph/reportbug/reportbug.git/

Che permette anche una notevole riduzione di dimensioni:

morph@alioth:~/reportbug$ du -hs reportbug reportbug.git/
35M     reportbug
1.4M    reportbug.git/

Ora c'è bisogno di modificare la descrizione del repository (quello che cgit/gitweb mostrerà):

echo "Reportbug - segnala bug per la distribuzione Debian" > reportbug.git/description

Si è ora pronti per copiare il repository risultante nella sua destinazione finale:

cp -r reportbug.git /git/reportbug/

Ora puntare il browser su https://anonscm.debian.org/cgit/reportbug/reportbug.git e buon divertimento! Per avere un repository locale sulla propria macchina eseguire:

git clone git://anonscm.debian.org/git/reportbug/reportbug.git
git clone ssh://git.debian.org/git/reportbug/reportbug.git

(a scelta, per l'autenticazione anonima e ssh)


?CategoryAlioth CategoryGit