KDE e cgit

Il progetto KDE utilizza cgit come frontend web per i repository git.
Il progetto cgit fornisce un accesso web super fast ai repository git, con
alcune funzione di utilità specifiche come il riconoscimento dei repository on-the-fly.
Sicuramente rappresenta una valida alternativa alle molteplici interfacce web
già presenti sul mercato.

How to destroy my fossil repository in one step!

Fossil and Git are two great softwares, and I use them day by day.

Unluckily the former has less support by integrated environment, IDE, and this makes a little easier to deal with Git when working with mainstream development frameworks. But luckily, Fossil has a way to export to Git and, much more itneresting, to do a bidirectional import/export that is to export and re-import a git repository. In other words, you can work on a repository with both git and fossil pretty much at the same time.

Today I decided to realign my fossil repo to a git one, so to have the same logs and timeline available both from command like (i.e., fossil) and IDE tools. But I messed up everything:

fossil export 

  --git 

 --export-marks /sviluppo/fossil/luca.fossil.marks 

  /sviluppo/fossil/luca.fossil

  | git fast-import 

    --export-marks=/sviluppo/fossil/luca.fossil

Who catch the error?

Well, the git mark points to the fossil repository file, not the mark file!

Boom!

A whole repository destroyed in a few seconds.

The only thing that can save in such a situation is a backup, but, shame on me, I didn't have a fully recent one, so I lost part of the history.

Lesson learned: always do a backup before acting on a repository, even if you are supposed to only read from it (as in an export phase).

Lesson learned: do not trust the shell to complete paths and filenames for you.

GitLab, PostgreSQL, e la perdita accidentale dei dati

Un socio di ITPUG ha indicato un articolo interessante riguardante un incidente informatico capitato a GitLab. A parte il tecnicismo e l'errore, forse grossolano e sicuramente dettato dallo stress e la fretta (chi è senza peccato scagli la prima pietra...), la parte interessante dell'articolo è l'apertura e la documentazione che GitLab ha voluto fornire a seguito dell'accaduto.
Sicuramente questo atteggiamento ha permesso a GitLab di uscire "meglio" dal disastro, poiché quasi tutti gli sviluppatori hanno apprezzato la documentazione fornita, che ha consentito uno studio postumo utile a chi si troverà in simili situazioni.

Magit migliorato ancora!

Era da un po' di tempo che non aggiornavo la mia versione di Magit, il front-end git per Emacs, e devo dire che sono rimasto molto colpito dallo sviluppo costante e accurato che il progetto ha avuto.

Certo, Magit non semplifica la vita a chi non conosce git, anzi è necessario conoscere bene il workflow di git per poter lavorare in Magit, ma la nuova gestione è veramente migliorata ed aiuta a districarsi fra le varie opzioni.

Infatti ora è disponibile un buffer con le abbreviazioni dei principali comandi, in modo da semplificare la scelta delle opzioni da seguire. Inoltre c'è un uso molto calibrato dei colori nei buffer, tanto che anche il buffer del commento di commit ora utilizza differenti colori per indicare le sezioni ignorate e quelle di testo effettivo. E a proposito del buffer dei commenti di commit: viene abilitato in default il flyspell (ovvero lo spellchecking al volo con evidenziazione delle parole sbagliate).

Complimenti agli sviluppatori per questo fantastico front-end!

git: rename a tappeto!

Mi capita spesso di impostare un repository git su un computer che non uso abitualmente; dopotutto il bello di git è proprio questo essere distribuito. Una delle cose che però scordo sempre, nella fretta, è di impostare lo username e l'e-mail che apparirà nei commit. Siccome tipicamente lavoro "da solo" su un repository, faccio abbastanza presto a rinominare tutti i commit sbagliati: il comando filter-branch consente infatti di agire sui commit di un ramo di sviluppo. Nel mio caso tutto si riduce ad un semplice:

git filter-branch --commit-filter '
                GIT_COMMITTER_NAME="Luca Ferrari";
                GIT_AUTHOR_NAME="Luca Ferrari";
                GIT_COMMITTER_EMAIL="email";
                GIT_AUTHOR_EMAIL="email";
                git commit-tree "$@";

        ' HEAD

Il trucco ovviamente funziona per commit non ancora resi pubblici. Il comando filter-branch consente anche di individuare particolari commit (ad esempio solo quelli sbagliati invece che tutti) e quindi di agire solo su tali.

git merge & commit message

E' stata apportata una modifica importante a git, il famoso DVCS sviluppato per il kernel di Linux e oggi utilizzato in moltissimi altri progetti. La modifica riguarda il merge di due o piu' rami: attualmente git effettua il merge in modo "silenzioso", inserendo un messaggio automatico che indica un generico "merge of ". Con la modifica apportata git chiedera' all'utente di inserire un messaggio personalizzato. Banale, ma molto efficace: anzitutto consente all'utente di motivare il merge, e in secondo luogo consente all'utente di riflettere fino all'ultimo sull'esigenza del merge e nel caso di annullarlo.

Lo stesso Linus Torvalds commenta così la nuova feature:

This change hopefully makes people write merge messages to explain their merges, and maybe even decide not to merge at all when it's not necessary.

I've been using that git feature for the last few weeks now, and it has resulted in my merges from submaintainers having various notes in them (well, at least if the submainter gave me any). So I'm trying to lead by example.

But if you don't like explaining your merges, this might be annoying. Of course, if you don't explain your merges, you are annoying, so it all evens out in the end. "Karmic balance", so to say.

Git reflogs

Git e' il sistema per la gestione delle revisioni che preferisco e che uso per la maggior parte dei miei progetti, alternando al suo fratello Mercurial.
Come e' noto, la capacita' di Git di lavorare con intricate connessioni di commit e di avere una storia non lineare e' superba. Esiste tuttavia un punto ove anche Git memorizza la storia in modo lineare: i reflogs.
I reflogs sono liste di identificativi SHA1, gli stessi usati per identificare gli oggetti in Git (commit, tag, ...). Lo scopo dei reflogs e' di associare ad una azione effettuata su un branch, ad esempio un commit, un punto nella storia. Ogni volta che un branch viene aggiornato (commit, checkout, merge, tag, rebase) viene memorizzata un'entry nel reflog indicando il tipo di azione, l'hash SHA1 di partenza, ove ci si trovava rispetto ad HEAD (nel tempo) e il messaggio descrittivo dell'azione.

Il seguente listato mostra una parte di reflog del progetto JFK:

$ git reflog
f16c3e0 HEAD@{0}: commit: Code clean up.
509b537 HEAD@{1}: commit: Inserted single includes for resources in the test goal.
c2d782b HEAD@{2}: checkout: moving from e3c164d49d5e50c42f90b9d142ef64ddc77c175c to master
e3c164d HEAD@{3}: checkout: moving from master to e3c164d49d5e50c42f90b9d142ef64ddc77c175c
c2d782b HEAD@{4}: commit (amend): Refactoring of the repository in order to use Maven for t
4c26949 HEAD@{5}: merge maven: Fast-forward
e3c164d HEAD@{6}: checkout: moving from maven to master
4c26949 HEAD@{7}: checkout: moving from e3c164d49d5e50c42f90b9d142ef64ddc77c175c to maven
e3c164d HEAD@{8}: checkout: moving from master to e3c164d49d5e50c42f90b9d142ef64ddc77c175c
e3c164d HEAD@{9}: checkout: moving from maven to master
4c26949 HEAD@{10}: checkout: moving from master to maven
e3c164d HEAD@{11}: checkout: moving from maven to master
4c26949 HEAD@{12}: commit: Refactoring of the repository in order to use Maven for the comp
e3c164d HEAD@{13}: checkout: moving from master to maven

Partendo dal fondo si ha che 13 modifiche prima dell'HEAD corrente (attenzione, le modifiche non sono per forza dei commit) si e' effettuato un checkout che ha portato HEAD a puntare dal ramo "master" a quello "maven". Analogamente si nota come "11 modifiche fa" si sia passati dal ramo "maven" a quello "master" per poi tornare nuovamente al ramo "maven" (10 modifiche fa).
L'hash riportato nella prima colonna indica a cosa puntava HEAD quando si e' svolta l'azione. Ad esempio nel caso della modifica 12 si aveva che HEAD puntava a 4c26949 (ramo "maven"); a seguito del cambio di ramo e successivo ritorno al ramo originario "maven" la HEAD e' tornata ad essere 4c26949. Questo perche' l'operazione 11 e' stata annullata dalla 10 che di fatto ha riportato la situazione di HEAD alla modifica 12. Analogamente la modifica 0 (HEAD corrente) punta alla HEAD corrente, come e' facile verificare con:

$ git log
commit f16c3e04a6220e5c246dda75832d3cb47890eb37


Riassumendo quindi si puo' dire che i reflog rappresentano un giornale delle azioni che hanno modificato la HEAD corrente (non importa su quale ramo si stia lavorando), e visto che ogni azione Git va a modificare la HEAD (commit, rebase, tag, branch, ...) si ha come risultato che i reflogs rappresentano la storia lineare del processo di sviluppo. In altre parole i reflogs sono il diario delle azioni svolte dagli sviluppatori sul repository, e volendo usare un brutto paragone sono una sorta di ".bash_history" del repository.

JFK available on GitHub

I promised JFK would have been available publicly, but then I was too much busy to publish it. I did it today, so you can access JFK source tree via GitHub. Enjoy it!

GitHub & licensing

Today I signed up for GitHub , the most famous Git-based on-line repository. Being involved in a few Open Source projects I signed up for the free account, and I noted two statements in the license agreement (do you read the license agreements when you sign up for something, don't you?) that pleased me a lot:

D.2 All of your Content will be immediately deleted from the Service upon cancellation. This information can not be recovered once your account is cancelled.

In contrast with a lot of other online services (not only related to source code management), GitHub assuers me that once I click "delete" all the copies of my work will be deleted, very good!

F.1 We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

So not only they will not keep "unauthorized" copies of my work, but they will not use my intellectual property as it was their property. In other words, GitHub will work as a "simple" network storage system for my code. That was what I was searching for.

SourceForge has similar terms, and in particular it does not claim any right on the intellectual property:

(from http://sourceforge.net/apps/trac/sitelegal/wiki/Terms_of_Use)
You retain your ownership rights to any and all of Your Content. Geeknet claims no ownership of any Content you submit to Geeknet. You or your third party licensor, as applicable, retain all intellectual property rights to any Content and you are responsible for protecting those rights, as appropriate.

but has a strange term for user deletion:

(from http://sourceforge.net/apps/trac/sourceforge/wiki/Removing a user account)
When an account is removed, the account name is not released back in to available name space. Under current policy, the deleted account name will not be reallocated to a new user.
Data created by the user on the site (such as forum posts, Tracker tickets, etc.) will remain intact, and will continue to be attributed to the account, even after the account has been removed.

It seems that a deleted account is simply denied to login again, but all the stuff remains there, even the account itself (otherwise there would be no reason to not push back the nickname on the available name space!).

I'm not saying that one system is better than the other, I'm just pointing your attention to a couple of things that seems interesting to me.

Git: import CVS e il ramo che ancora deve nascere...

Git e' un ottimo sistema di controllo delle versioni, con una filosofia totalmente differente rispetto a CVS (si potrebbe anche affermare che Git nasce dall'odio per CVS...). Non c'e' quindi da stupirsi quando l'uso combinato di Git e CVS possa dare qualche grattacapo inaspettato. A me e' capitato un problema eseguendo un cvs import di un repository cvs "pulito":

fatal: refs/heads/origin: not a valid SHA1
fatal: master: not a valid SHA1
fatal: You are on a branch yet to be born


Ebbene dopo diversi tentativi ho trovato la soluzione: cancellare la directory $HOME/.cvsps e la directory .git e rieffettuare l'import del modulo.

Pl/Java & Eclipse: importare il progetto in Eclipse e usarlo con Git

Pl/Java è un linguaggio procedurale che sfrutta Java all'interno del database PostgreSQL; l'idea è quella di poter usare/riutilizzare codice Java all'interno del backend PostgreSQL. Ho tenuto una dettagliata presentazione del linguaggio e del suo funzionamento interno alla CONFSL 2010.

Dare un'occhiata ai sorgenti di Pl/Java è un ottimo esercizio di programmazione, ma purtroppo come per altri progetti PostgreSQL-related, i sorgenti sono disponibili su un archivio CVS! Se come me non amate molto CVS e preferite sistemi piu' flessibili, come ad esempio Git, ecco i passi da fare per caricare il progetto in un vostro repository locale con tutta la storia (è necessario abbiate CVS, git-cvs e Eclipse con relativo plugin egit installati).

Per prima cosa creiamo il repository e scarichiamo i sorgenti e la storia dal repository CVS:

mkdir pljava-git

cvs -d :pserver:anonymous@cvs.pgfoundry.org:/cvsroot/pljava login

cd pljava-git && git cvsimport -v -d :pserver:anonymous@cvs.pgfoundry.org:/cvsroot/pljava org.postgresql.pljava

Il processo richiederà circa 10 minuti, a seconda anche della banda disponibile. Al termine avrete all'interno della directory pljava-git il repository locale sul quale lavorare.

Non resta quindi che importare il tutto in Eclipse: avviate la procedura di import di un nuovo progetto, scegliete Git come tipo di progetto e specificate la directory appena popolata. Ovviamente non dovete creare un progetto nuovo, ma un progetto esistente a partire dall'albero dei sorgenti.

A questo punto avete pieno accesso al repository anche da Eclipse e potete iniziare a navigare nel codice e a sviluppare!

GitCast

Ho scoperto quasi per caso, anche se è ben visibile nella sezione di documentazione del sito ufficiale di Git, un sito che contiene una serie di mini cast sull'utilizzo delle varie componenti di Git: gitcast.

Backup semplice con git

Utilizzo git per tutti i miei progetti importanti, e come ogni buon utente che si rispetti, tendo a non fare mai backup del mio albero dei sorgenti (se non in momenti assolutamente inutili, come le vacanze di Natale!). Ebbene git puo' semplificare la creazione di una copia di scorta live dell'albero dei sorgenti: è sufficiente creare un repository remoto da aggiornare di tanto in tanto.
Detto fatto! Sulla mia chiavetta usb ho clonato i repository che mi interessano con:

git clone /sviluppo/java/eclipseWorkspace/mioProgetto

dopodiché devo solo dare un bel

git pull origin

dalla directory della chiavetta usb che contiene i progetti da aggiornare. Così sulla mia pendrive ho sempre una copia quasi aggiornata (con tanto di storia) del mio albero dei sorgenti.

New GIT repository for Aglets

After a quite long suffering with the CVS repository provided by SourceForge, I moved the Aglets code base to a GIT repository, still hosted at SourceForge (see the official news).
I haven't moved the official CVS module aglets, but instead I've integrated my own branch which includes the new threading scheme, the new GUI (based on Swing), the new message queueing and the full localization of all messages.
I hope this change will ease the development and, in the meantime, attract new developers to work on the code base. Quite surprisingly the number of project members is growing, even if the commits are not, but of course there must be time for new members to learn the code before they can work on it!
At the moment the documentation is still on the CVS repository, but I guess it will be migrated sooner or later. The CVS repository is still active, in order to allow GIT-newbies to take a look at the code without having to use GIT, but CVS will be disabled soon so I recommend using the GIT repository instead.

Importare un progetto SVN in Eclipse gestendolo con Git

Al fine di meglio apprendere Git, il sistema di gestione dei sorgenti appositamente sviluppato per il Kernel di Linux (ma usato anche in altri progetti), ho deciso di convertire un progetto Java che gestisco con un repository SVN in un repository Git.
Su questo progetto lavoro pressocché da solo, usando Eclipse e i tools SVN sviluppati dal gruppo di SVN stesso, quindi non dovrei molti problemi nella migrazione. Per sicurezza ho deciso di mantenere per alcuni giorni entrambi i progetti in Eclipse, così da poter tornare abbastanza semplicemente al sistema SVN in caso di problemi.
Di seguito i passi necessari all'installazione di EGit, il plug-in per Eclipse/Git e per l'importazione del progetto.

Installazione del plug-in per Eclipse: EGit
L'installazione del plugin non è un'operazione banale, poiché occorre importare i vari sotto progetti in Eclipse e compilarli a mano. In particolare occorre seguire i passi:

• scaricare i progetti di EGit in una directory temporanea con il comando git clone git://repo.or.cz/egit.git
  

• importare i progetti in Eclipse. Per fare questo selezionare da Eclipse il menù File->Import->existing projects into workspace e verificare che i progetti compaiano nel project explorer.

• ora occorre compilare i progetti, per fare questo occorre darre il classi Build-All dal menù Project. Questo passo è opzionale se avete abilitato il build automatico dei progetti.
• occorre ora esportare un plug-in compatibile per Eclipse, quindi dal menù File->Export si seleziona la voce Plug-in and fragments. E' necessario impostare come percorso la root dell'installazione corrente di Eclipse.
  

• a questo punto è possibile riavviare Eclipse, cancellare la directory temporanea dove si sono scaricati i sorgenti di EGit, rimuovere i progetti dal project manager e verificare che il plugin sia installato. In particolare per questo è sufficiente controllare che nell'import ci sia una voce Git.

Conversione di un progetto SVN in repository Git
Nel mio caso il progetto SVN si chiama HRPM e risiede su una macchina remota. Dopo aver installato sulla mia macchina tutti i tool git, fra i quali git-svn, posso importare il progetto SVN in un repository locale git con la seguente procedura:

• creare una directory dove inserire il repository, entrare nella directory e inizializzare il repository git: git-svn init svn+ssh://host/sviluppo/svn//hrpm
• importare i sorgenti con il comando git-svn fetch -r900 (dove 900 rappresenta il numero di revisione a cui il repository SVN è arrivato)
• dopo qualche secondo (o qualche minuto), il repository git sarà pronto al suo utilizzo. E' ora possibile usare questo repository o importarlo in Eclipse.
• (opzionale) siccome il progetto importato nel repository contiene lo stesso nome del suo fratello su SVN, qualora si vogliano mantenere entrambi i progetti è necessario editare il file .project che si trova nella directory dei sorgenti cambiandone il nome, come ad esempio in HRPM-git.
  

Importare il progetto in Eclipse
Avendo ora il progetto su un repository Git è possibile importare il progetto all'interno di Eclipse:

• dal menù File->Import->Git selezionare la voce Git-Repository;
• selezionare nella dialog che si apre la voce file e specificare il percorso dove risiede il repository git;
  

• la dialog successiva chiede quale branch si vuole importare. Siccome il repository è appena stato creato, il branch master è quello selezionato per default.
  

• a questo punto il progetto è importato, ma non ancora visibile in Eclipse: esiste la cartella corrispondente nel workspace, ma non il progetto nel project explorer. Per far comparire il progetto, è necessario procedere ad una successiva importazione di un progetto esistente: File->Import->Existing Project into Workspace come mostrato di seguito

• si specifica la directory che contiene il progetto (ATTENZIONE: questa volta si deve specificare la directory all'interno del workspace) e si vedrà comparire il progetto fra quelli selezionabili. Qualora esista già un progetto con lo stesso nome Eclipse non mostrerà nessun progetto selezionabile.

• e il progetto verrà visualizzato nel project explorer. Non è ancora finita, perché il progetto è locale, e non verrà gestito da Git. Occorre quindi fare click destro sul progetto, selezionare Team->Share Project e usare Git come metodo di condivisione.

• da ultimo si informa Eclipse di usare un repository esistente, e il gioco è fatto.

La cosa interessante è che il procedimento ha funzionato perfettamente nonostante il mio progetto fosse non un semplice progetto Java, bensì un progetto AspectJ. L'unica pecca del plug-in, almeno ad una prima vista, è l'utilizzo dei caratteri in stile CVS per indicare che il contenuto necessita di commit/aggiornamenti, mentre l'uso delle icone del plug-in SVN è sicuramente più gradevole.

Link utili:
Eclipse Git Plugin Installation
A dummy guide to use Egit