The VASL devs are planning to switch from Subverison to Git for version control soon. I had not been planning to do this until V4, due to difficulties with converting our existing svn repo to git, but as a side-effect of helping the VASL guys convert their repo, I figured out how to convert ours as well. So, if we wanted to, we could switch to git at any time without losing any of our history. (In fact, our history would be a bit improved by switching to git. In svn it’s hard to follow the history back further than revisions around 990, when I finished reorganizing the svn repo, and I found a way to straighten that out when converting to git.)
So, there are two issues to consider:
-
Do we want to switch to git now?
-
If we switch to git, do we want to use github.com for git hosting?
Regarding #1: There’s a git plugin, EGit, for Eclipse. It looks easy to install, and there is a general git tutorial and a user guide. Git’s documentation is thorough and there is a tutorial specifically for people switching from svn, as well as a general tutorial. I’m an experienced git user, and I’m also happy to answer questions. Coming from svn, I can say that it took me a few days to understand how git works, but after that I never wanted to use svn again.
Regarding #2: With git, your working copy is a complete repo in itself. (This is not like svn, where what you have in your wokring copy is just the branch and revision you have checked out.) Because you have all of the data locally with git, you can very quickly switch between branches in your working copy. You can also very easily apply commits from branches in other repos to branches in your own repo. The way people tend to use git is to have their own repo for the project, into which they periodically merge changes from other developers. (Merging tends to be painful in svn, but is usually simple in git.) What we do for one of my company’s products is that each developer has his own repo, and then we have a master repo where we keep the canonical state of things. So, the branches belonging to each developer in svn end up as a developer’s repo in git, while the trunk in svn ends up as our master repo.
That said, GitHub makes all of this very easy to do. You have an account, you can create as many public repos as you want, and then your local repos track those public ones at GitHub. You push local changes out to those public repos on GitHub. If you want to merge changes from some other repo, you do a pull from that repo—which you will have access to because it’s a public repo on GitHub.
SourceForge’s setup for git hosting is not as nice. The history browser for GitHub is far better than SF’s, and that’s something I find myself using often. It also looks like you have to be a project admin to fork (i.e., copy) a repo, so there ends up being some friction with getting set up. One thing I’m convinced of is that it’s a good thing to have your own repo to mess with, because it frees you up to do things you might not do otherwise without having any fear of borking things in an irrecoverable way.
So:
My inclination is to switch to git regardless of where we host our public repos, but also to use GitHub for hosting them.
Are you guys amenable to this?