It is not clear that the DokuWiki community wants to have this idea implemented. See also Discussion of this idea.

The idea is to let DokuWiki optionally use Git as backend. That means

• There needs to be an abstract storage backend
• There need to be implementations of that storage backend for the current mechanism and Git

This backend should only be used for old revisions, the current revision should be stored in that storage system, but still the plain text files in data/pages/ should be read. For Git a pure PHP implementation like glip should be used.

Advantages of this approach:

• Git is much better at storing a long history efficiently than what we currently have (a compressed full copy of the page for every revision), the same will be true for mediarevisions
• The history could be synced with a remote Git server
• Git could be used to create branches so a certain namespace could start at a certain point in the history of another namespace and yet both pages would have the full history available
• Multiple instances of a wiki could be edited simultaneously offline and later merged.
• You could update your wiki from your favorite $EDITOR!

Disadvantages:

• At least in the versioning part DokuWiki will no longer follow the KISS approach
• It might cause a performance loss (but when the current page is viewed)
• The pure PHP Git implementations only implement the basics, I (michitux) don't know if one can easily implement the efficient storage you get when using git gc and also branching doesn't seem to be implemented in PHP. There are bindings for libgit2 in development here.

• You need to know PHP and especially the inner parts of Git (a start might be Gittin Down to the Plumbing) or at least quickly understand the concepts behind Git
• You need to be able to understand larger (but not that difficult) parts of DokuWiki in order to be able to see where the new API needs to be used

Hard There are already some wikis based on Git so you don't need to start from zero, but you will have to read and understand a lot of code unless you should already know Git very well, then that task won't be that difficult. You will also need to change code in a lot of places in DokuWiki as we don't have any file access abstraction for accessing stat information (reading/writing is already done in central functions).

Discussion: I'm not sure if this would be as hard as you make it sound. If the data/pages directory was in git, the only change absolutely necessary would be to commit the change each time something has been written to disk (inside the data/pages directory). That would give you quick and easy git back-end storage. The difficulty level on this should be fairly easy, because as was mentioned above all the writing is done in central functions. This basic level of functionality would allow people to clone the repository and keep it on their local machine, edit, and merge back.

The next level of complexity that could be added on after this is incorporating git's history to replace the use of the data/attic directory. There are two big benefits to this: 1) When you revert a page the version tree would look better (and make more sense) to people looking at it from the git side 2) the storage of all that text is much more compact as git only stores differences not a whole copy for each change.

Finally, if you want to get really fancy (and expend a LOT more effort) you could enable features such as branching where you can have multiple different versions of pages live at any time, then merge them back together eventually (or not). I'm not personally convinced that this is very useful. I definitely wouldn't want a feature like this to hold back something simple like the above features.

However, these things wouldn't be necessary for a baseline capability.

The following people volunteered to “mentor” any new developers taking up this task by answering questions, giving tips and reviewing code:

• Adrian Lang

There is a plugin that implements a gitbackend in current DokuWiki but depends on git, so not php-only. See gitbacked plugin.