Ready.

Nothing more to say, actually.

• 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 -r to see all the remote branches known to you. Remote branches have generally a name in the form origin/$branchname, because origin is the default alias that is given locally to the remote repository.

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.

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

1. 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
2. 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
3. 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
4. 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

This is the second presentation that I will give next Thursday: the topic is the infamous tivoization.

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.

• 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)

Fonte: http://milano.repubblica.it/cronaca/2011/04/12/news/attentato_a_belpietro_la_procura_non_ci_fu-14841079/