Housekeeping
cp /usr/share/zoneinfo/America/Los_Angeles /etc/localtime # ... because there is no /usr/share/zoneinfo/America/San_Francisco /etc/init.d/ntp-client restart
Ready.
Add comment February 3rd, 2012
Posts filed under 'Languages'
My standing about 3D movies
http://theoatmeal.com/blog/3d_movies
Nothing more to say, actually.
Add comment December 25th, 2011
Yet another GIT branching guide
If you always work on the master branch, git pull and git push commands are just what you need. If instead you need to work on a branch, something more need to be said. First, some explanations.
- GIT uses branches just like SVN: a branch is a different path of developement
- There is no implicit “primary” branch (SVN has instead the “trunk”); that said, the main branch is often called master (GIT will give this name to the main branch when creating an empty repository).
- Branches can be either local or remote:
- A local branch is a branch that exist on the local repository only; you can see a list of local branches using
git branch. - A remote branch is instead a branch that exists on a remote repository, therefore visible to anyone that has access to it. Use
git branch -rto see all the remote branches known to you. Remote branches have generally a name in the formorigin/$branchname, because origin is the default alias that is given locally to the remote repository.
- A local branch is a branch that exist on the local repository only; you can see a list of local branches using
Now, before creating a branch, you may want to ask yourself some questions:
- Do I want to propose some changes to the world, or instead do I just want to try out some things?
- Do I need to follow another guy’s branch, or am I working alone on the subproject?
If you need to work in team, you need to create a branch on the remote repository (if someone else did not already) and then setup a local branch to “link” to it (GIT calls this tracking); otherwise, you just need a local branch.
Let’s start from the easy part: how to create a local branch.
Local branches
Suppose that I am following the master branch, but I want to try the foorazor approach to the problem. I create a “topic” branch just for that:
git branch foorazor git checkout foorazor # or, in a single command: git checkout -b foorazor
Now I start working on it, making commits and whatever. If, some time later, I see that the foorazor approach is wrong, I just delete that branch:
git checkout master # to switch to that branch git branch -d foorazor # delete the wrong branch # If the branch content was not merged (and this is perfectly fine sometimes), GIT complains with: # error: The branch 'foorazor' is not fully merged. # If you are sure you want to delete it, run 'git branch -D foorazor'. git branch -D foorazor # so, just force its deletion
If, instead, the foorazor approach turns out to be useful, I merge it back in the master branch:
git checkout master git merge foorazor # you may need to manually merge some things here, if there are conflicts # edit the files with conflicts, git-add them when ready and git-commit to resolve the merge git branch -d foorazor # delete the now unneeded branch, if no development is needed anymore on that topic
Note that no git push was ever made: we never informed the central repository of our local branch. If, of course, I have completed the work on foorazor and I have merged it, now the code exists also on the master branch, so the next git push will transfer those commits to the central repository.
Working with a remote branch
Let’s take branches to the next level. Someone asked me to work on his awesome branch to fix some bugs. I have already fetched the whole repository with git clone, so the remote branch is already known to me:
$ git branch -r origin/awesome origin/master
Since I know that there is nothing awesome in fixing bugs committed by other people, I decide to track the awesome remote branch with a descriptive local name: (there is no need to have different remote and local names, I do it to point out the namespace differences)
git checkout --track -b boring_work origin/awesome
Now I work on the local branch boring_work as always. I fetch my friend’s changes with git pull and do commits locally; when I want to give him back my changes, I type:
git push origin boring_work:awesome
This command pushes the changes from the local boring_work on the remote branch awesome on the repository origin: note that you can use just git push origin awesome if you used the same name locally (and probably you should do so if you are not an advanced user).
NOTE FOR ADVANCED USERS: by default, if no remote branch name is given on the command line (remember that the syntax is git push ${reponame} ${local}:${remote}), GIT pushes to a remote branch with the same name of the local one. So, even if boring_work tracks origin/awesome, git push origin boring_work will create another branch called boring_work on the remote repo. This happens because the configuration option push.default has a default value of matching (see man git-config). Solutions?
- Either use a local name that is the same of the remote one (
git checkout --track -b awesome origin/awesome); - or, if you want more freedom, configure the local repo with
git config push.default upstream, that says GIT to push the current branch to its upstream branch, not the one with the same name.
— NORMAL USERS, RESUME READING HERE —
When I’m done helping my friend, I just type
git checkout master git branch -d boring_work
and forget about the past.
How to create and delete a remote branch
What if I want to create a brand new branch on the remote repository?
This command creates a branch called new_branch, as a copy of the remote’s master (actually, as a copy of the remote’s HEAD, but, if nobody messes up the remote repo by actively running commands inside it, the result is the same):
git push origin origin:refs/heads/new_branch
Now you can fetch it locally as explained above.
If instead you want to duplicate a remote branch, use:
git push origin origin/old_branch:refs/heads/new_branch
Note that none of the previous command sets up a local branch.
To delete a remote branch, just use:
git push origin :remote_branch
that can be remembered easily as “using remote repo origin, push “empty” to remote_branch“. The deletion command does not need the “refs/heads” prefix because the branch name is already known remotely and therefore can be looked for in the standard places.
1 comment September 9th, 2011
SVN to GIT repository migration
Last week we at NetGroup decided that it was time to move our SVN repositories to GIT. While I always use svn-git to interface with Subversion, a server-side move was long awaited.
Here follows a step-to-step migration history, loosely based on this article, that I found as the most useful resource on the Web among those suggested by Google. I publish the code here to help you migrate as well 
Preparation
First of all, I listed all the active SVN authors in the repository. From an updated SVN working copy, I created an authors.4git file:
svn log --xml | grep author | sort -u | sed 's:.*>\(.*\)<.*:\1 = :' > authors.4git
I filled the output file with actual username information, using the following syntax:
username = Name Surname <mail.address@example.com> username2 = Name2 Surname2 <mail.address2@example.com> (no author) = no author <(no author)>
The last line is important for those commits that lacked an author (from a even older CVS2SVN migration).
Fetch and convert branches and tags
I started to fetch the SVN repo using git-svn:
git svn clone ssh://path/to/old/repo/ --authors-file=authors.4git -s svn2git_tmpdir cd svn2git_tmpdir
Some sources suggest to use --no-metadata when cloning, but I wanted to preserve SVN commit information in the GIT log: you’ll see later why.
Then I converted SVN tags to actual GIT tags:
for t in `git branch -r | grep 'tags/' | sed s_tags/__` ; do git tag $t tags/$t^ git branch -d -r tags/$t done
I removed most of the leftovers from git-svn:
git branch -d -r trunk
git config --remove-section svn-remote.svn
rm -rf .git/svn .git/{logs/,}refs/remotes/svn/
In the end, I converted the SVN branches, that git-svn created as remote GIT branches, into actual GIT local branches:
git config remote.origin.url . git config --add remote.origin.fetch +refs/remotes/*:refs/heads/* git fetch
Additional tweaks: history and commit messages rewriting
Since the migration is a one-time effort, before completion I wanted to fix some longstanding issues in our repo.
The first one was the removal of some useless commits: a couple of times someone managed to commit loads of useless files, forcing someone else to revert that commit. So, I found the SHA identifier of the oldest of those commits and launched (note the tilde sign at the end):
git rebase -i ${OLDESTBADCOMMIT}~
GIT fired up my $EDITOR and I removed all the useless commits (both the adding and the reverting ones), by deleting the appropriate lines in the configuration file.
The history rewriting was successful. I had to type a couple of times:
git reset git rebase --continue
because some commits became empty ones and I wanted to discard them. The git rebase had to be run on all the branches that included those useless commits (hint: use git branch --contains ${BADCOMMIT}).
The second problem was the preservation of the SVN metadata inside the GIT commit logs. This was needed because some SVN commit messages referenced other SVN revision numbers, so I wanted to keep those references intact. On the other hand, the previous git rebase had mangled the GIT-committer property of the rewritten commits, by setting me as the committer, even if the author property was left intact (you can see the difference on an actual GIT repository using git log --format=fuller). Both issues can be solved with one command:
git filter-branch -d /tmp/tmpfs/gitrewrite \
--msg-filter 'sed "/git-svn-id:/s;^.*/\([^/]*\)@\([0-9]*\).*$;Autoconverted from SVN (revision:\2, branch:\1);"' \
--env-filter 'export GIT_COMMITTER_NAME="${GIT_AUTHOR_NAME}"; export GIT_COMMITTER_EMAIL="${GIT_AUTHOR_EMAIL}"; export GIT_COMMITTER_DATE="${GIT_AUTHOR_DATE}";' \
-- --all
The -d switch ran the operation (that is said to be I/O intensive) on a tmpfs mount. You can skip it if the history is short enough, or if you don’t care about it.
The first filter edited the git-svn-id lines into a prettier format; the second one restored the GIT-committer properties that I had lost previously.
In the end, --all runs those filters on all the branches.
Push to the new repo
Before pushing to the new repo, I let GIT collect the garbage by pruning unreferenced objects:
git gc --aggressive --prune=now
And, finally, I completed the migration by pushing everything on a bare, empty repository that I had already set up:
git push --all ssh://path/to/new/repo.git git push --tags ssh://path/to/new/repo.git
To complete the operations, I removed the temporary directory and refetched everything, just to be sure:
cd .. rm -rf svn2git_tmpdir git clone ssh://path/to/new/repo.git local_repo_dir
And voila, now you’re using GIT 
Add comment July 28th, 2011
The truth about Naples
I love Naples.
Everyone loves Naples.
I like watching Naples.
Watching Naples can be a social event, unless you’re in a couple. And even in that case you might have a chance to enjoy it.
It’s good to be in Naples. Usually.
It’s possible to go around for Naples.
You can talk about Naples in the comments of this message.
1 comment June 6th, 2011
I quesiti referendari del 12 e 13 giugno 2011
Visto che non se ne parla molto in TV, un breve riassunto dei quattro quesiti referendari su cui gli italiani saranno chiamati ad esprimersi i prossimi 12 e 13 giugno 2011.
- Scheda rossa: abrogazione dell’affidamento a privati del servizio idrico
- Vota SI chi vuole che il servizio idrico non sia gestito da privati
- Vota NO chi non è interessato a limitare questo affidamento
- Scheda gialla: abrogazione delle “logiche di mercato” nel settore del servizio idrico privato
- Vota SI chi vuole che il servizio idrico privato non sia autorizzato a trarre del profitto aumentando le tariffe dell’acqua: le tariffe dovrebbero essere calcolate solo per permettere alle imprese private il recupero dei costi
- Vota NO chi lascerebbe alle imprese private il diritto di guadagnare e fare profitto aumentando le tariffe oltre il solo recupero dei costi
- Scheda grigia: abrogazione del nucleare in Italia
- Vota SI chi vuole che in Italia non si costruiscano centrali nucleari
- Vota NO chi non è contro la costruzione di tali centrali sul territorio italiano
- Scheda verde chiaro: abrogazione della legge sul legittimo impedimento
- Vota SI chi vuole rimuovere la possibilità che il Presidente del Consiglio ed i Ministri della Repubblica hanno di non presentarsi in tribunale nei processi a loro carico
- Vota NO chi sostiene che il Presidente del Consiglio ed i Ministri della Repubblica possano non presentarsi in tribunale nei processi a loro carico
Add comment June 3rd, 2011
Fighting tivoization with the GPLv3
This is the second presentation that I will give next Thursday: the topic is the infamous tivoization.
Add comment May 24th, 2011
Patent Trolls against the Open Source Software
Next Thursday, I will give a speech about a couple of OSS-related topics. This presentation is about the first one: the relationship between patent trolls and Open Source Software.
Add comment May 23rd, 2011
L’inversione della paura
Mi sono chiesto a lungo se intitolare questo post “La paura dell’inversione” o “L’inversione della paura”. Entrambi descrivono la sfilata del Torino Pride di oggi, pur da aspetti diversi.
- Banalmente, “La paura dell’inversione” è quella che caratterizza parte delle persone autodefinitesi “normali” quando si confrontano con il movimento gay. Un ventaglio di emozioni, il cui semiasse negativo varia dal timore del diverso alla sua repulsione in quanto contaminante.
- Più interessante è “L’inversione della paura”, titolo che ho scelto perché mi trasmette un messaggio di speranza.
Inizierò da lontano.
Prima della sfilata di oggi, molti conoscenti non gay con cui ho discusso del Pride hanno espresso un guidizio sostanzialmente negativo, riassumibile in: “se i gay vogliono chiedere uguaglianza di diritti, una sfilata di Carnevale non è il migliore dei modi”. In altre parole, secondo molti, gli eccessi della sfilata rischierebbero di alienare i giudizi degli indecisi.
Beh, se per “eccesso” si intende questo qui sotto, bene, qualche eccesso oggi c’è stato.
Ma il Pride non è solo questo. Ieri (20 maggio) sera ho avuto una conversazione, breve ma illuminante, con un gruppo di gay dichiarati. Uno di questi ha descritto con particolare profondità la sensazione di isolamento e di paura che un giovane con tendenze gay, magari ancora acerbe, vive al contatto con il mondo. Sia che venga riconosciuto e apostrofato come “frocio di merda”, sia che scelga di reprimersi e viaggiare sottocoperta, la paura è una delle emozioni più comuni. Paura del guidizio altrui, paura delle reazioni dei cari, paura di subire fisicamente e psicologicamente le conseguenze di un’insieme di scelte non comuni.
Dunque, il Pride agirebbe come invertitore della paura, come manifestazione di un’amore diverso, come cassa di risonanza per raggiungere quelli che hanno paura e urlare loro: non siete soli. Per un “esterno” come me, il Pride è soprattutto questo.
(tutte le foto sono prese da Torino Repubblica)
Add comment May 21st, 2011
Non per dire che l’avevo detto, ma…
Il 1° ottobre 2010 Belpietro non scampò ad un tentativo di attentato. Perlomeno, questo ha accertato la magistratura. Comunisti.
Add comment May 20th, 2011
