RDTN on GitHub

I created a repository for RDTN on GitHub. This is currently only a fun experiment and not a replacement for the subversion repository; the SVN at TZI is still the “official” repository for RDTN. I push the main line of development (trunk in SVN, master in git) to both GitHub and the subversion, although I might update git more frequently.

To try it out, install git, if you don’t have it already, and than use

git clone git://github.com/jgre/rdtn.git

This will download the current master branch to a newly created rdtn directory. If you want a different name for the directory, just append it to the clone command. There is a lot of documentation on git and at least one book in preparation, so I don’t include any more usage information here. Instead, I will talk about the reasons for this experiment and some cool features of git and GitHub.

Why git?

I have been using git locally for working on RDTN for some time now, synchronizing the repository with git-svn. The primary motivation is that git gives me painless branches. Even if RDTN is not a big project, branches are very useful. I often start implementing stuff of which I’m not sure how long it will take, if it breaks other stuff, or whether it’s a good idea at all. Sometimes none of these questions can be answered even when it’s time for the first commit. But then I don’t want any broken implementations of half-baked ideas in the trunk, so unless I created a branch when starting to work on the idea, I end up with a huge commit with a vacant commit message, as I don’t really recall all the details.

While using subversion, I tended to think: “Nah, no need to create a branch for this. That’s easy to do and it won’t break anything.” Of course, that assumption was wrong more often than not. The reason for the tendency to avoid branching is that with subversion, creating a branch is a real effort: you have to create a copy in the repository, check it out, and change to the directory. And when you want merge, you need to look into the log to find out in which revision you created the branch or where you merged before. And you also have to remember to commit the merge (I often forget this and end up with a commit that includes the merge and some further changes).

I’m not saying that branches in subversion are impossible or that subversion users are stupid and ugly, but if your ideas seems rather simple, branching is a real trade-off. With git, however, there is no excuse for not creating a branch: just say

git checkout -b crazy_idea

and you’re done. Git also makes merging easy by doing all the things right that subversion does wrong: it keeps track of what needs to be merged and it commits the changes right away (unless you tell it not to or there is a conflict).

Another git feature I really like is commit –amend. (I must admitt that I have not researched if subversion has something similar.) This allows you to change a commit after the fact. The use-case is simple and common: You implement something and then commit it with a detailed commit message and then notice you forgot to add the file where all the work happens or some other really stupid mistake. The common reaction is to fix it and quickly commit with a lame message such as “Added missing files”. With commit –amend you tell git: “Oh, and this change also belongs into the last commit”.

So far this should explain “why git?”, the question “why put the stuff on GitHub?” is still open.

Why GitHub?

Working with git locally and pushing changes to the subversion server with git-svn works really well and it solves my main workflow issues. So using a public git repository would not really be necessary. The deciding motivation is experimentation. GitHub is quite popular in the Ruby community and I came into contact with the service through my work on rubinius. I liked what I saw, so I wanted to play with it some more with a project of my own.

Having a public git repository allows us to collaborate on git branches. So far this hasn’t been crucial for the work on RDTN, but it still may prove to be useful.

A really interesting feature of GitHub is that it allows you to attach comments to diffs. Some time ago I looked into tools for code review such as Review Board and Rietveld. The idea of these tools is that a contributor submits his changes to the review application before committing it to the repository. Other developers comment on the code, the contributor improves his patch and finally the changes are accepted and can be committed. The process is something like asynchronous pair-programming, which I think is generally a good idea.

However, as far as I understand these application, the contributor has to have uncommitted changes sitting around in his working directory until someone takes the time to review the stuff. Working on other changes while waiting for reviews probably becomes a bit of a hassle with such a work-flow. The review application also needs to keep track of updated diffs so that reviews can see what was changes in response to their comments. In this video Guido van Rossum talks about an internal Google review program called Mondrian the main ideas of which later became part of Rietveld. At some point he talks about how Mondrian keeps track of the changes to the proposed changes, which to me sounded a lot like he implemented yet another version control system in the review tool. I wonder if his requirements weren’t be better served by a distributed version control. Git and the diff comments on GitHub seem to be just that better solution. Unfortunately, I haven’t really worked with these features yet, but I’m looking forward to a chance to do so.

Conclusion

If you are working on RDTN and interested in using git, clone the repository from GitHub and try it out. When you have changes that you want to get merged into the repository, send me an email and we sort out, how we want to handle this.

The easiest way is you send me patches created with git format-patch. But you could also setup your own git repository on GitHub using the fork function and then I merge from there. I could also give you commit access. I don’t know what’s the best process, so we have to just try it out.