Git

Instead of using Subversion for developing MediaWiki you can use Git's gateway.

Why use Git instead of Subversion?
The major reason to use git-svn is because you like git more than Subversion. You'll wind up with a git repository that you can use like any other git repository. "git svn rebase" will fetch all commits and rebase your changes, "git svn fetch" will seemingly fetch much more including ridiculously long checkouts of new branches that you'll probably never look at, and "git svn dcommit" will commit your changes.

Everything is absurdly fast, as usual for git. Except for checking out updates from SVN. That's absurdly slow. As in "go get some coffee while you wait if you didn't rebase in the last few days". And if someone makes a new branch it takes approximately 1.47 eternities to check out with git svn fetch. I don't know why this is so slow, I asked in #git but they blamed it on SVN. Oh well. But you can use git.

Is MediaWiki migrating to Git?
Not yet, but there's a lot of talk. Currently there are some outstanding Git migration issues as to how to lay out the repositories and what effect it will have on some automated and semi-automated workflows.

In the meantime, you can still benefit from mirrors or git-svn for some uses... keep reading!

Using the Mediawiki SVN Mirror on Github
There's an existing Mediawiki SVN Mirror hosted on Github. To get it do:

git clone git://github.com/mediawiki/mediawiki-svn.git

Using the Mediawiki SVN Mirror on Gitorious
There's another existing Mediawiki SVN Mirror hosted on Gitorious. To get it do:

git clone git://gitorious.org/mediawiki/mirror.git

Creating your own mirror
Clone MediaWiki's SVN repository into a new directory called "mediawiki". git svn clone --stdlayout http://svn.wikimedia.org/svnroot/mediawiki

If you have commit access, use this command instead. git svn clone --stdlayout svn+ssh://svn.wikimedia.org/svnroot/mediawiki

The resulting git repository contains the full history of trunk, branches, and tags to work on locally. However, the cloning process does take several days to complete.

Working with Git
The following documentation all assumes you're working with a remote Git repository created as discussed above.

Checking out new branches
By default you only track the  branch which corresponds to Subversion's. To check out and track another branch do:

git checkout -b REL1_15 --track origin/REL1_15

Rebuilding SVN metadata
TODO: If I get someone else's Git conversion how do I get it into a form like I'd  it? See this for an example that doesn't work. It gives:

$ git update-ref refs/remotes/trunk origin/svn/trunk fatal: origin/svn/trunk: not a valid SHA1

Commit / dcommit
First commit your changes locally as usual, e.g.,

git add foo.php includes/bar.php git commit

Then look them over and play with them if you like. When you're ready to commit them upstream, assuming you have commit access, you can run

git svn dcommit

This will check your commits against the origin, and commit any that you have and the origin doesn't. Of course, if you don't have commit access, you can still keep your local commits if you like, since git is a DVCS. will rebase them against any upstream changes, although needless to say, you have to manually fix any conflicts.

Links

 * Git's website with documentation
 * An introduction to git-svn for Subversion/SVK users and deserter by Sam Vilain
 * A git branching model