Hi, I think most people on this list already faced the issue: wikis are cool, easy to contribute, ... but it's hard to force yourself to use a purely web-based tool to interact with something which really looks like a version-control system. One solution is to use a git-based wiki, like ikiwiki [1], golum [2], ... but in many contexts, this is not applicable: because one has an existing wiki and doesn't want to migrate, because the git-based wiki lacks features XYZ that you rely on, or because one is a small contributor to a large project (say, wikipedia) and cannot force the project to change. I'm thinking of an alternative to this: implement a foreign VCS interface for a wiki engine. Today, one can interact with, say, SVN, using Git (via git-svn [3]). This way, we can get most of the Git goodness locally, and just "publish" the changes on an SVN repository. I think that should be feasible to implement the same kind of things to interact with, say, MediaWiki. Typical scenarios would be: 1) Work locally, possibly collaboratively on a set of pages, and then publish them on a wiki (let's call this "git mw set-tree" by analogy with "git svn set-tree"). 2) Wait for user contributions on the wiki, and fetch them to the Git repository with one command (let's call this "git mw fetch" by analogy with "git svn fetch"). 3) Allow one to easily download a set of files, and later get updates (i.e. "git clone/git pull" is far better than downloading from a browser) I'm personnaly interested in this in a teaching context, since I love Git, and I use a wiki [4] to publish some documents to my students. Scenario 1) corresponds to teachers preparing stuffs (without necessarily publishing drafts), and 2) corresponds to two cases: coworker unwilling to use Git, but willing to use a wiki, and students contributing some content. Senario 3) corresponds to the case where we distribute a set of files (say, example pieces of code), and reference these files from a wiki documentation. See [5] for an example. I've already got half a solution where I publish content on GitHub, and include them on a wiki with the "Include" extension [6]. It solves scenario 1) partially and 3) nicely, but not 2). Together with Sylvain Boulme (in Cc), we plan to propose a project to students to develop a git-svn-like interface to interact with mediawiki. Students have a bit less than a month in May-June and work in teams of 2 to 4 students (last year, we got the textconv functionality in "git blame" and "git gui blame", and some better error messages with the same project). It sounds feasible to write a usable prototype, probably re-using code from tools interacting with mediawiki (like wikipediafs [7]), and basing the work on git remote helpers [8]. We should be able to make this a free software. Among the design goals: * No restriction on the Git workflow. Unlike "git-svn" which promotes a flow with SVN as the central repository, we should target a workflow where people merge freely using Git, and then publish/fetch changes from the wiki (i.e. a merge-based workflow, as opposed to a rebase-based one). * Ability to import only a subset of the wiki (nobody want to "git clone" the whole wikipedia ;-) ). At least a manually-specified list of pages, and better, the content of one category. * Ability to work interact with several wikis (e.g. a test, private instance, and a public instance). And then, fancy extensions can be imagined: * Manage non-text files as Media files uploaded to the wiki. * Manage directories in Git as subcategories in the wiki. Any opinions? Advices? Does this sounds like a good idea? Any pitfall to avoid? Thanks in advance, Footnotes: [1] http://ikiwiki.info/ [2] https://github.com/github/gollum [3] http://www.kernel.org/pub/software/scm/git/docs/git-svn.html [4] http://ensiwiki.ensimag.fr/index.php/Accueil (French) [5] http://ensiwiki.ensimag.fr/index.php/LdB_-_Modes_d%27adressages#Mode_d.27adressage_.C2.AB.C2.A0Indirect_Registre.C2.A0.C2.BB [6] http://www.mediawiki.org/wiki/Extension:Include [7] http://wikipediafs.sourceforge.net/ [8] http://www.kernel.org/pub/software/scm/git/docs/git-remote-helpers.html -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html