Recently I was about to start a project where I didn’t know quite well what direction it was going to take. So I was there, experimenting and hacking code here and there while investigating where would it bring us, when I realised that I would like to have a snapshot of the code at that point, before continuing with the next part. The classic solution would have been to make a .zip of the code folder, or a copy of the folder in the above directory, and continue. But if you want to compare between versions, manually calling diff between file versions is cumbersome. I didn’t want to add the code to the subversion repository because it was by no means ready yet for anything. So I though: why don’t I use git for this?

First steps were a bit uncertain, but I quickly developed a simple yet effective command line technique. Yeah, no IDE plug-in whatsoever, I am just using a bash terminal. It works pretty much like this:

• code code code
• looks good! let’s store this…
• git add file1.cpp file2.cpp ………. or git add . for adding all changed files to the commit
• git commit (so that I can enter more than one line of commit message, in the editor that shows up) or git commit -m ‘commit message’ for one liners.

Sometimes, when I want to see what has changed, I use gitk. It is admittedly ugly but once you get it, it’s nicer than reading plain diff output in a terminal screen. Specially because you can navigate between changes, instead of having to manually invoke diff for each file you want to compare.

At a certain point I wanted to make a huge code change, so I made a new branch. Actually, I haven’t gone back to the other branch since then, but it’s good to know it’s there in case I want to see how the code is in that totally incompatible code and class-wise approach to the problem.

Probably one of the things I like more is that everything is lightning fast. Since the repository is stored locally, there is no more waiting for commits to finish or contacting the server for getting a diff. Even if your Subversion server is in your local network, it will never beat the experience of a localhost, direct disk access based repository. This way, one doesn’t get distracted with the check in/commit process; it becomes an almost automatic action so the mind can be focused in the real problem: the code!

If you’re an advanced git user, you might have already realised that I am only using a very reduced set of git features. Whether that’s sad or not, I leave it up to you; I just wanted to highlight the notion that although git is generally used (or was designed) for huge projects with lots of collaborators branching and merging intensively and all that, it is actually very good for producing what I call code sketches, and it doesn’t need to be used by several users with all the clone, pull, push and rest of single-worded verbs paraphernalia to enjoy its power.

Please don’t understand this post as a subversion sucks, use git square-headed litany, but rather as a friendly git could be quite useful, if you have some spare time you might consider having a look at it suggestion from a long-time Subversion user who knows Git is intimidating but worth the effort to learn :D

But I’m still not completely keen on using them, because there are two things that can be done only with subversion: checking out only a folder, out from the complete hierarchy. And externals.

Although technically one could check out only a folder with git (or that’s what I could deduct from what I read), it is still kind of awkward/buggy and very far from being as intuitive as it is with subversion. When I looked for info in mercurial docs, it directly said it wasn’t possible.

Now it seems google code is offering project owners the possibility of switching from subversion to mercurial, but I am going to keep using subversion there too. I don’t think anyone is going to want to branch any of my supersnippets but you never know ;) — I moved the project to github! You can now branch it if you want :D

You may argue that I could do with lots of mini git repositories for each folder I might possibly want to check out, but knowing myself as I do, that’s just calling for a disaster to happen. I would probably forget to clone/update the most important repository before going offline, you know, that kind of things. It works better for me to keep a single repository with a nice hierarchy of miniprojects that I might occasionally extract or use as externals in other projects.

Just give me those two features and I will be completely convinced to switch to a DVCS (i.e. Distributed Version Control System) :-)

With SVN (Subversion) it’s much easier. You continue building your stuff locally and when you’re happy with it, check it into your Subversion server. Then you log into your hosting server with ssh, and in your /web directory do something like svn co http://mysubversionserver/project/trunk . – that will associate the /web directory with the subversion repository path /project/trunk. Meaning that each time you do changes and commit them to SVN, you can get all the changes rolled to your server by simply connecting with ssh and running svn up in the /web directory.

Obviously for doing this you need a hosting account with ssh access. Most of them do not have such thing, and I really can’t understand how could I survive without ssh access before. Even for simple things such as deleting a directory, ftp’s and sftp’s are terribly slow :-)

There’s more sophisticated people which are using build makers like ant or the famous capistrano to deploy stuff but for the moment I still don’t need that degree of complexity; it’s not worth the effort yet.