Why I'm leaving Subversion for Git

I always believed in Subversion's potential and that it would be a wide improvement over the nightmare that was CVS, but I found out that, as Linus says, There is no way to do CVS right.
Subversion is fairly good and it's probably the better centralized version control system on the market, and it's open source. But after my first day of Git real-world usage, I now cannot negate that the distributed model of Git will be superior at last.

For example, in Git, you are not forced to have a remote repository: you can start with your local repository, and commit to it. No need to set up server software if you don't want to, as your machine is already your own server.
After working locally for some time and having done very fast commits as you usually did much more slowly with your remote Subversion server, you can push or pull changesets to other repositories. I was worried about the inherent uncertainty in this process (which branch? Which repository?), but Git tracks the origin of your repository, precisely the common ancestor in the remote branch, which your master branch was forked from. When you start by cloning a remote repository (as it is almost always the case), it will push to that origin. But you can also push to nearly everything, even if there is not a common ancestor.
The converse is true: you can also pull to update your repository from an external one, that may be your point of convergence. Obviously, you can also pull from everywhere, in a local branch if you are not sure to incorporate the changes.

The commit access notion vanishes in Git. You and I typically do not have commit access to major projects such as Zend Framework or Doctrine anyway (ok, I have to Doctrine, but when I come out with a small patch I just put it the bug tracker for a review), and we have only our working copy, having to upload patches to the bug tracker. Multiple versions of those patches. That quickly become not in sync with the current revision of the codebase.
Collaboration between working copies is difficult, as an official branch is needed. Moreover, it's rare that you know a branch is needed ahead of time. If for every feature you started a remote branch, even with Subversion (which has cheap copy-on-write branches) the development would be very slow. So many times you end up working on the trunk and struggling because you cannot break it, and sending patches by email. These problems are described in Linus's talk at Google about Git - which is amusing. When I watched his talk using Subversion really started bugging me; I knew that here was an alternative, and it consisted of mature software since the talk was old, from 2007.
What's the solution then? In Git everyone has his own repository, so you can just pull changes from other people and pushing changes to them. There is no commit access, only a group the lead developer trusts and he will pull from. This group may pull and review from other people, in a hierarchical work flow where a chain of trust is established. For an open source project, Git is worth its weight in gold (which actually I don't know, but it will be surely expressed in hexadecimal.)
You can break your repository if you want, committing all the day without problems, and being able to revert to every commit's revision as if Git were a time machine, and very cheaply (in Subversion you are forced to hit the network to revert to revisions older than the last commit.) When you have fixed your copy after ten, twenty or an hundred commits and all tests are passing, you may finally push. Awesome.

And this was only my first day in Git!