Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time
163 lines (102 sloc) 6.52 KB
What’s the project’s current status?
Have a look a the “Things that work” section in the README.
If you’re interested in how active the project is, check the commit history on
So, you’re running MediaWiki with Git as backend?
No. Currently, Levitation has nothing to do with _running_ MediaWiki at all. I
seriously doubt it is worth the effort to adapt MediaWiki for a Git backend.
Instead, a new frontend should be developed.
Okay, so you’re planning to fork Wikipedia?
Me? Probably not. But I know some guys who might be interested in doing it. And
since I think that yet another centralistic Wikipedia is not the solution, I’m
experimenting in a different direction. Namely, a distributed Wikipedia.
But with Git, won’t every contributor need gigabytes of history?
First, if you haven’t heard about “git clone --depth” yet, have a look at it.
Second, my vision is to have 5 to 20 “Wikipedias” per language that focus on
different aspects and have different policies. These would be hosted by someone
having enough resources to do that, and editing articles would be done via a
web interface as it is now.
The difference to today is, that the Wikipedias can easily transfer content
between each other, including history and using Git’s powerful merging
capabilities. Additionally, everyone who wants to clone the whole Wikipedia can
do it, with full history, and without waiting for a monthly dump. Instead,
pulling from Wikipedia gives you the content as it was at that second.
Also, Git developers are currently working on the possibility to retrieve just
parts of the repository.
Wouldn’t it be better to split the data into several repositories?
I can’t think of a good way to do that. Where do you draw the line?
Most people suggest “one repo per article”. That’s probably the best “line”
there is, but how would you then move/rename/merge articles without losing
Currently, this project is about mapping a MediaWiki history to a Git history
while losing as litte information as possible. As soon as that works, we could
think about using git-filter-branch or something like that to split it into
saner chunks.
Would Levitation allow to incrementally import changes made in the current
centralistic Wikipedia into one’s local Git clone?
I think so. There are some possible issues though.
If, for example, you would update only one article’s history and then another
one’s, history would be in the wrong order and need to be rewritten. Git can do
that easily, but the incremental importing tool would have to consider that.
Another problem could be that articles you have in your local clone might get
deleted upstream. If they are, they no longer show up in dumps _at_all_.
Would Levitation allow it to make changes to the local clone and maintain these
changes even when importing new stuff from the current centralistic Wikipedia?
Yes, that’s something that happens all the time in distributed development.
Keep the upstream Wikipedia in one branch, your changes in another, and
frequently rebase or merge. With things like git-rerere, you can minimize the
amount of manual merging conflicts.
Would Levitation allow it to make changes to the local clone and push them back
to the current centralistic Wikipedia?
Absolutely, just like git-svn does. Nobody has written that code yet, and I
doubt that _I_ will do it, but it should be pretty straightforward.
It looks to me as if importing gets slower and slower the more recent the
commits become, right?
Maybe a bit (because the trees get larger), but actually not as much as you
probably think. Levitation shows you the date in history while it writes the
commits, and indeed the time it takes to finish one day is apparently
increasing. However, for most Wikipedias, the number of commits per day is
constantly increasing, so there’s simply more work to do per day.
Why are you doing this anyway?
Because I love Git and the development model DVCSs allow, because I’m fed up
with de.wikipedia’s attitudes on policy and because I think using Git is one of
the better solutions. I would hate it if other people developed another
software that’s essentially as flawed as the current Wikipedia model.
Me too, how can I help or say “thank you”?
If you’re looking for the “donate” button:
Writing, improving and debugging Levitation is a considerable amount of work.
Unpaid work, and I’m a pretty broke student. Your donations will help pay
external hard drives to import larger Wikipedias, and basic stuff like paying
the rent.
If you don’t want to give money, you have plenty of other options:
Play around with it and tell me about your experience.
If you’re good at Python, rewrite some of my code to be less ugly. One commit
per change please, I’m a control freak.
If you’re a Git guru, I’d love some hints about how to make the resulting repo
smaller and improve overall performance. If you know a Git guru, ask him.
If you own a powerful box, import a large wiki and get in touch with me, I’m
interested in size and performance.
Implement some of the “Things that are still missing” (see README). Please ask
me in advance before doing larger changes to avoid your patch getting rejected.
I have invested about a week of work in this tool, any material gratification
would be greatly appreciated. Have a look at, which
is continously updated. I also like gift certificates. :)
If you, like me, don’t have that much money to spend it on other people,
writing patches and spreading the word about Levitation is an option as well.
So, write blog posts or talk to people on Git and Wikipedia mailing lists
about the project.
I have a question that’s not answered here.
Check or send me a patch to this FAQ containing
your question. :)