REP1 Migration to Git for version control


Ruby currently uses Subversion for version control. This REP proposes to move it to Git, and set up a Subversion mirrors for people who need it.


In 2008 quite a few important projects in the Ruby space moved to Git (Ruby on Rails, Rake, RSpec, RubySpec, Rubinius and others),and seen number of contributions from the outside of "core team" greatly improve. [citation needed] Thanks to distributed nature of Git, and isolated repositories, experimentation of all sorts andintegration of results that proven itself to work for core committers is much easier thanit is with a centralized version control system.

Switching Ruby development to Git will have a learning curve for some community members, but eventually willincrease the speed at which Ruby the language, CRuby virtual machine and Ruby standard library evolve. It will alsogreatly simplify integration work core team members are doing, as well as backports, because excellent branching/merging iswhat Git was originally created for.

Why Git and not other DVCS.

Git is already quite popular with the Ruby community. Large number of Ruby projects use Git, and RubyForge eventuallyadded Git support because of that. Just a short list of Ruby projects using Git:

  • Ruby on Rails
  • RubySpec
  • Rubinius
  • RSpec
  • Merb
  • DataMapper
  • RSpec
  • Treetop
  • Rake
  • Cucumber
  • Haml
  • Extlib
  • Sinatra
  • Mack

and many others. Git has a killer app that Ruby community adopted: GitHub.

Git pros.

  • GitHub is only available for Git
  • Distributed
  • Handles branching/merging very well
  • Performs very well, very space efficient
  • Large vibrant community
  • Does not require local clones for both long living and short living branches


  • Windows support is not as good as one of Subversion or other version control systems.
  • Has certain learning curve initially.
  • Rubys SCM toolchain is focused on Subversion.
  • Wide, sometimes arcane interface and documentation

Migration process.

Ruby core team has a toolchain that needs to be migrated to work with Git.

  • commits are reported on the ruby-core mailing-list
  • commits are referable by their commit ID (rXYZ in svn)
  • commit messages are scanned for Issue IDs. Issues are updated respectively.
  • source-code makes use of svn keywords like $Id$, $Date$

Other options

Other Version Controls Systems should also be considered.


Mercurial has slightly better learning curve and tries to be more friendly to Subversion users.It performs wonderfully well for an application written mostly in a very high level language,and has most of features Git has, though some of them require plugin set ups. Local branchesin Mercurial mean lightweight local clones in most cases.

Mercurial has GitHub rip off called bitbucket, but "fork, do the work, send a pull request"on github requires way less effort and Ruby community has no significant presence atbitbucket.

Mercurial users enjoy cross-platform experience thanks to Python.


Bazaar is still the slowest of The Big 3.

It may perform good enough though. Bazaar has good Launchpad integration, butmisses the point of easy "fork, do the work, send a pull request"workflow completely compared to GitHub.

bazaar leans towards lightweight local clones for local branches, which mayor may not be a problem, compared to the tree you sit on

Darcs, Arch, ...

Darcs, Arch, Monotone and others have small community and thus possibly may requireextra work on the user side if something goes wrong. Darcs has ill fated performanceproblems (they may not be the case for 2.0 though) and is in haskell, so not that manypeople can actually improve/fix it when needed.


Feel free to add your arguments below, but please leave author signature next so people can follow up on the mailing list, and so forth.Transcripts and summaries of ruby-core discussions are very welcome.