Git

When I started working several years ago, we were using CVS as version control system (VCS) and I didn't really liked it. It was obvious that the CVS team took some design decisions that were completely wrong so it was quite a pain to use. But CVS was first released in 1990, so it was already an old software, and maybe at that time the knowledge on how to do VCS was not really advanced.

After using CVS for a while we started looking for alternatives, and the quick and easy solution was to use Subversion (SVN). SVN was released in 2000, the goal of SVN developers was to build "a better CVS" (so users would be familiar with the commands but without all the CVS bugs and missing features). There are tools to convert a CVS repository to SVN, so we did. And life was already much more beautiful 😊.

But after using SVN for a while, you see some of its shortcomings. In the overall, for most projects, it's good enough. During the years they made SVN better and better. At the beginning merging was a nightmare, nowadays it's much more easier, but when you look how they did that, it looks like a hack and not a very good one. But I don't think they could do much better considering how SVN was designed.

Few years ago, lots of buzz started around DVCS (distributed VCS) and around Git specifically. Git was initially developed by Linus Torvalds for managing Linux kernel source code.

For my daily work, SVN does not cause any trouble (to me at least), so we don't need to spend time to look for a new VCS. I'm actually starting a pet project (I will post something about it if I manage to get something useful) and I decided to give a try to Git (it's good to try new/different things, note to myself: I should to that more often). So I started using Git few days ago and I'm quite impressed by it.

Some of the features I like:

• It's fast. OK, my repository is currently very small, we will see how it evolves in the future, but Linux kernel is about 15 millions line of codes I think and about 10,000 commits between each release. It seems Git can handle a quite big repository.
• It displays correct binary prefixes. When cloning/pushing to a repository you see the size and download speed in MiB and MiB/s (or KiB and KiB/s).
• You can't get your repository screwed (i.e. corrupted). Ok, I never really had the problem with SVN either, but it can occurs in SVN. However I definitely get SVN in some strange status once in a while.
• It's distributed (no kidding 😉). The thing I like about that is I can do commits even if I've no network connection (being distributed has also other advantages but for the moment I'm the only developer on my project).
• I can regroup commits. Lets say I start working on a feature, I do an important modification, my project is in a bad state, but I want to keep a trace of that state, so I commit. I continue working, doing commits each time I think I do something important. At the end, I can regroup in one commit all those related commits.
• I can commit line by line! That's a neat feature. Imagine I did 2 modifications in a file, one that I just want to keep on my development version and one for the feature I'm working on. I can say that I want to commit one modification but not the other one. On SVN I had to copy the modification I didn't want to commit, revert that part of the code, commit the file and put back my modification.
• I haven't checked that yet, but given they way Git works, merging is very easy.

SVN was known to be "CVS done right" but as Linus Torvald said: "There is no way to do CVS right". From what I have seen and understood on how SVN and Git work, Git is obviously much well designed than SVN.

I think even in a small project, you can get benefits by using Git instead of SVN and on bigger projects I think the Linux kernel development is a proof that Git works pretty well. But using Git may need you to change the way you use your VCS usually. For instance, I think the way KDE team(s) could not use Git the same way they are using SVN right now (in fact they have a project to move to Git and they are obviously going to split their current SVN in several Git repositories).