What Does Everyone Think Of Switching To Git/github?

[k776]

I've been hosting a mirror of the 0 A.D. source code for some time now on the popular Git hosting website, Github. See https://github.com/0ad/0ad

With Philips recent graphics proposal, it got me thinking that it might be a good time to migrate to using Git as our code management system.

Philips changes are going to affect every player (for the better or for the worse), and I'm a strong believer that the main branch of a project (trunk/master) should always remain stable, and working, in case a user grabs a copy of that code to try. We don't want them to have a first time bad experience because of some in progress code.

As Philips changes are implemented, it could be some time before all kinks in the new system are worked out. Even if Philip completes the work locally first, he won't know if it works for others until he commits it, at which point, it could then break for users when it should be working.

So I proposed using a branch to keep the changes in until they were stable and tested. However, SVN is notorious for having poor branch/merge support. We need something better if we're going to do that. This is where Git comes in.

The biggest issues I've heard on the switch to Git are these:

* Windows users cant use it - This used to be a problem. When git first gained popularity, you needed a command line on windows to use it. However, there are a few decent tools now that work on Windows (including a TortoiseSVN clone called TortoiseGit - http://code.google.com/p/tortoisegit/). So you don't need to worry about alienating users.

* Git downloads the whole history - Yes, but that can be a good thing. Taking a look at old commits or the commit log is much much quicker than it is with SVN. And at the end of the day, you only end up downloading about 20% more IIRC (last time I checked). It's not several GB to download, only about 500mb. IT also downloads quicker. From our current SVN, it takes 6 hours to do a full checkout. With git, 45 minutes. Not too shabby!

* Autobuilds can't commit to the repo - This is true, and while it could be fixed, Git's 'download all history' nature would mean each autobuild would be committed and downloaded each time. Not ideal. Instead, we can easily create the binaries and upload them to Github's download page. Users simply download the latest binaries and put them in the right directory. Not difficult at all.

* There is a learning curve - Sure, there always is with new stuff, but it's not by much. And I'm very familiar with Git, so I'd be here and on IRC to help with any queries.

What we gain by switching to Git/Github:

* Excellent branching and merging support which will be very handy for multiple devs to support multiple branches of work, and easily pull in changes made by other devs. No more time consuming patches or single person development! Multiple people could work together on the same thing!

* Ultra efficient history packing (20% more, you get all 8 years of 0 A.D. commits). Getting new commits after that is super small/fast too.

* Github.com is an excellent Git hosting solution. The socialness of it makes contributions extremely easy to do. An interested person simply 'forks' (github uses the term for duplicating the codebase to your own account) the code, makes the change, commits and pushes it (unlike SVN, a commit doesn't go online until you push the code) and sends us a 'pull request', a Github feature which has file change view (per file), code change view (per line) and comments (for discussion, really good for feedback on things that need improving). Overall, it'll make the contribution process for interested devs more streamlines (no more trac or tickets to have to manage, just make the code).

What does everyone think? Is there any solid reason why can't at least try use Git, maybe for a week? If it doesn't work out, it should be fairly simple to make a patch of all the changes in Git and apply them to the SVN if we decide to go back to that.

[Ykkrosh]

The graphics changes aren't significant enough to cause serious instability - it'll be incremental additions, and you could edit the config file to switch back to the old mode if it's particularly broken. Also problems will be found and fixed much earlier if development is in the trunk. Extremely few users use SVN versions directly (compare feedback count before/after release) so they won't hit any problems that do exist. Also the graphics work will probably be finished before we could decide anything about Git. So I don't think this case is a reason to switch now. I like DVCSs in general, though, so it's still worth considering for the longer term.

I think a much better approach would be:

* Set up a read-only Git mirror of the SVN repository. (Already done). Maybe set up an Hg one too, for people who prefer that (e.g. me).

* Ensure that mirror is always up-to-date (perhaps automatically via an SVN post-commit hook or similar) so people have no reason to prefer SVN.

* Encourage people to check out from that mirror instead of from SVN. (We mention it somewhere here but not prominently.)

* When people have changes they want to submit, they can push changes to their fork on GitHub and then post on Trac with a link to their changeset or attach a patch or whatever, which is pretty trivial to do.

* Some WFG member can review the change, give feedback, wait for a new patch, make tweaks, etc, then apply it as a patch to SVN and commit it. (If the person in the previous step is a WFG member, they can skip the review and apply the patch and commit themselves, which is also pretty trivial - it's what I do anyway since I use a local Hg mirror for development.)

That's far less effort and risk than switching all our development to Git, and I think it provides almost all the benefits. If it turns out that everyone loves the new approach, we could do a more permanent transition later; otherwise we haven't lost anything or wasted any significant time or caused anyone unnecessary bother.

[janwas]

When I last used it (right about the time Philip started the HG clone), TortoiseHG was a rather rough-around-the-edges shadow of its TortoiseSVN counterpart. The TortoiseGit screenshots look a little nicer, but there is still the risk of alienating users (Git being quite a different model).

My sympathy for DVCS is definitely increasing - there have been several network outages (more of a problem for SVN), glitches (tree conflict and HTTP 405 that require revert+delete+update+try again, ugh) and better merging would indeed be good.

However, I agree with Philip that we can already have most of the benefits (via mirror), that this particular situation and others foreseeable in the near future don't require DVCS, and also believe that switching mid-project is to be considered very carefully. Would the significant effort of completely switching over be recouped by the increased efficiencies of Git? Doubtful at this fairly late stage.

[k776]

Far more active projects have made the switch from SVN to Git, like Ruby on Rails (https://github.com/rails/rails) and JQuery (https://github.com/jquery/jquery), and they coped with the work required to get people up to speed. So compared to them, the effort for us to switch to Git is minimal. We only have about 5-6 people committing at the moment.

there is still the risk of alienating users (Git being quite a different model)

Not if we amend the documentation. The only change for someone who just pulls the code to play would be changing from a 'svn update' command to an 'git pull'.

this particular situation and others foreseeable in the near future don't require DVCS

But wouldn't it be best to do that now, when the need isn't great and the amount to people who need to swtich are few, than wait till we have 2x/3x devs (maybe) and make it nearly impossible to switch? At least by doing it now, those who haven't used Git will have time to get used to it, and those new to the project won't have to worry that we ever used SVN. And I'm always available to help on the IRC if someone is lost.

Would the significant effort of completely switching over

Significant? The mirror exists, I can commit to it right now if I needed to. All someone has to do is clone it, and they can commit too! At most, you spend 45 minutes downloading the source again, but then you're good to go. It's not significant effort at all.

[Ykkrosh]

Far more active projects have made the switch from SVN to Git, like Ruby on Rails (https://github.com/rails/rails) and JQuery (https://github.com/jquery/jquery), and they coped with the work required to get people up to speed. So compared to them, the effort for us to switch to Git is minimal. We only have about 5-6 people committing at the moment.

They're projects whose users are programmers, and whose developers are definitely programmers, so they don't seem particularly comparable to a game whose developers are often non-programmers. Also, they're far more active projects so there's much more value in them using a DVCS than in us using one.

The only change for someone who just pulls the code to play would be changing from a 'svn update' command to an 'git pull'.

Almost nobody pulls the code just to play - players use releases, and developers will have to learn a load of new commands and a fundamentally different conceptual model.