Re: Gate between git and mediawiki : remote-helpers

["Jérémie NIKAES" <jeremie.nikaes@gmail.com>]

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.