Extension:GitSynchro

Cette extension GitSynchro, que je suis en train de développer, a pour but de télécharger et de téléverser les pages d’un wiki MediaWiki au travers de wikipedia:fr:Git.

La raison sous-jacente à cette extension est la possibilité d’éditer hors-ligne un wiki, puis de téléverser sur le wiki en-ligne dès que la connexion Internet est retrouvée. Pour en avoir discuté avec plusieurs personnes, cette fonctionnalité d’« édition hors-ligne » peut combler un certain besoin, mais les avis divergent sur les usages qu’il faudrait en avoir.

Vu que cette fonctionnalité n’existe pas, cette extension apporte une possibilité technique. Ensuite, elle devra être testée en conditions réelles et les workflows devront probablement être ajustés. Noter également que Git n’est pas un logiciel très user-friendly mais les technologies sous-jacentes sont assez puissantes, aussi « l’édition hors-ligne » ne se fera probablement pas directement avec Git (sauf pour les personnes expérimentées), mais au moyen d’interfaces graphiques exploitant Git en interne pour les aspects stockage local et synchronisation distante.

Exemple

Accès en lecture seule :

git clone http://wiki.seb35.fr/Extension:GitSynchro

Avancement

• Lecture
• Écriture
  • Authentification avec l’extension auth_request de nginx
    • Création d’un module à ajouter à l’API renvoyant 200/401/403 selon si la requête est ok/mauvaise authentification/interdite
    • Utilisation de AuthManager pour se connecter au moyen de l’API clientlogin pour récupérer un jeton qui sera utilisé par le hook Git qui fera l’écriture au moyen de l’API edit
  • Hook Git réalisant l’écriture effective dans MediaWiki des commits reçus
    • Le hook Git le plus adapté est amha update pour avoir une possibilité de refuser en cas de conflit d’édition
    • Édition au moyen de l’API edit en récupérant le nom du serveur dans l’adresse "email" du committer, mais pour cela il faut récupérer à un moment donné le mot de passe du committer (qu’il a entré lors du push) ou un jeton émis à la suite de l’authentification du push
• Création d’un hook client Git prepare-commit-msg destiné à formater très exactement le message de commit, car s’il n’est pas exactement conforme à ce que le serveur crée de son côté il faudra que le serveur le modifie et crée un commit différent, ce qui ferait diverger à chaque push le client et le serveur

  Dans cette même logique, il faut que le client ait accès à l’ensemble des informations nécessaires à la création d’un commit ; par exemple, j’avais envisagé d’inscrire le numéro de la révision MediaWiki dans le message de commit, mais le client n’a pas cette information ; en revanche, il serait éventuellement possible, si cela a un intérêt, d’inscrire l’identifiant interne du texte committé, qui est simplement le SHA1 du texte, donc connu du client

Git flavour

J’ai déjà eu l’occasion de créer une passerelle Git – cf Archéo Lex visant à publier la loi française sous Git – et, une fois la technique de base achevée, de nombreuses questions apparaissent sur la façon d’organiser les choses, et de façon sous-jacente les workflows et les usages. Dans Archéo Lex, je citerai deux exemples :

• en légistique française, il y a certains textes qui n’ont pas encore de date de publication (car en attente d’un décret, etc.), mais Git n’a pas cette notion de « date inconnue à déterminer ultérieurement », il faut donc définir une convention
• les lois peuvent être toutes rangées dans un seul répertoire à raison d’un fichier par loi, mais Git ne sait pas avoir plusieurs historiques distincts dans un seul répertoire ; donc il faut un répertoire par loi, mais met-on un seul fichier dans ce répertoire ou fait-on des sous-répertoires par livre, section, article ? Rassemble-t-on l’ensemble des lois dans un répertoire principal versionné avec des sous-modules Git ? (ou d’autres technologies Git de séparation d’historique comme les subtrees ou les subrepos)

Ici, il est probable qu’un repo Git corresponde à un article avec son historique propre, et donc en conséquence un sous-dossier par article, chaque sous-dossier contenant un unique fichier.

Le format du message de commit devra être arrêté, en tenant compte des diverses contraintes ; il peut y avoir plusieurs formats potentiels, mais un seul par wiki.

Ensuite, la première difficulté d’organisation et d’utilisation viendra lorsqu’il faudra gérer plusieurs articles. Les interfaces graphiques prendront probablement en charge la synchronisation sous-jacente des historiques. En ligne de commande, il faudra probablement créer une commande permettant de visualiser l’état de la synchronisation d’un ensemble de fichiers/articles.