Thank you for the advice regarding the project. Here is its status : - We decided with your advice to use remote helpers, using the syntax mediawiki::http://url.com (thanks to Sverre Rabbelier & Junio Hamano) - We created a github at the following url https://github.com/Bibzball/Git-Mediawiki On it you will find * Our source code featuring - A start of a remote helper. The functions currently supported are described on the wiki - The import part, for which we would like to thank Jeff King for his initial perl code that we used and altered to realize the import function of the remote helper - The export part is for now only a quick application of the mediawiki API to export a file * A wiki with the basic documentation on our project Feel free to consult it and give comments / ask questions In order to maintain coherence between revisions (mediawiki) and commits (git), we have to store metadata somewhere. Since we want to keep transparency on the mediawiki's side, we want this data to be stored in git. Git notes seem to be a good answer here. They could contain the revision numbers that correspond to the commited files. Also, a commit with t files on git should be t revisions on mediawiki. We identified a few issues : * Conflicts : - A git user wants to push files - He is allowed to do so : no new revisions were made on mediawiki - The git user starts to push the files one by one, using the mediawiki API - A mediawiki user edits one of the files queued up in the for-push list and saves his modifications -> The git user should be interrupted in his process. If not, the changes of the mediawiki user will be overridden. We still don't have a solution for this problem. Our guess is that we should send each file in 2 steps. a) get the timestamp of the last revision of this file from mediawiki b) send the file, if allowed to, based on this timestamp * A tree from mediawiki is necessarily linear. The tree from git can have multiple branches. Let's have this example : - The mediawiki has been cloned on our side - We made changes and committed them - We want to pull changes from the mediawiki 2 solutions from here : a) Pull including merge Pros : The tree is saved on our side. If someone wants to clone our repository, he will keep this structure. Cons : Because of mediawiki's trees linearity, keeping branches on our side forces us to pull again right after the push in order to maintain coherance between mediawiki revisions and git commits. b) Pull -- rebase Pros : We are very close to mediawiki's structure, facilitating synchronisation. Cons : Forbids other git users to clone my repository since some of my branches might die after a rebase. This, in our opinion, kind of goes against some of git's principles. To you, which solution do you prefer ? Do you see any alternative ? * We would like to have the alternative to clone only partially the mediawiki (for example, only a few pages). Let's illustrate this one : - A user clones pages a, b and c - Later on, he wants to add another page d to his clone list -> The entire history/tree has to be remade as commits have to be inserted in between others Thank you for your support on this project. If any information reported was not clear enough, feel free to ask questions. Any contribution / suggestion is welcome. Regards, The Git-Mediawiki team, Arnaud Lacurie, David Amouyal, Claire Fousse & Jeremie Nikaes. -- 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