Ma vie sans GitHub - partie 2: git send-email🔗

Il y a quelque temps, j'ai décidé de quitter Github, en fermant mon compte. Depuis, j'expérimente des modes de contribution au logiciel libre de manière à peu près décentralisées.

Aujourd'hui, nous allons voir comment contribuer à un développement avec l'aide de git et du bon vieux courrier électronique via la commande git send-email !

Globalement le mode opératoire est assez simple:

• Vous avez un clone du dépôt central.
• Vous faites des modifications donc des commits.
• Une fois que vous estimez que vos changements sont dignes d'êtres soumis au(x) responsable(s) du projet, vous utilisez git send-email.
• De son côté, le responsable du projet utilise git am pour récupérer vos modifications.
• S'il a des remarques à faire, il vous les renvoie en réponse à votre courrier électronique où finalement toute l'action de négociation se déroule (en privé par défaut).
• Une fois que tout est ok pour le responsable projet, il intègre vos changements (ou non) et votre contribution est intégrée au projet (ou non).

Pour faire simple, git send-email propose un système proche des pull-requests de Github mais en passant par le canal complètement décentralisé du courrier électronique.

C'est plutôt une proposition intéressante, car elle permet un développement immédiat avec quelques outils dont, à peu près tout le monde est équipé (git et une adresse de courrier électronique).

Avant de commencer, sachez que sous Debian, git email-send n'est pas installé par défaut avec le paquet git (ce qui est sans doute dommage). Vous pouvez l'installer via:

# apt install git-email

Ensuite, avant de pouvoir utiliser git send-email, il faut configurer git pour accéder à votre serveur de courrier électronique.

• D'abord, vous devez savoir à quelle adresse de courrier électronique envoyer vos modifications (project@thesuperproject.example dans la suite de l'article). Cette configuration sera bien entendu différente pour chaque projet et elle doit être locale au dépôt git.

git config --local sendemail.to project@thesuperproject.example

• Ensuite, vous aurez besoin d'indiquer quel serveur SMTP sera utilisé pour réaliser l'envoi du courrier électronique proprement dit. Ces éléments de configuration seront sans doute indépendants du projet sur lequel vous travaillez. Vous pouvez donc les déclarer en global:

git config --global sendemail.smtpServer smtpserver.example
git config --global sendemail.smtpServerPort 25
git config --global sendemail.smtpEncryption tls
git config --global sendemail.from myaccount@smtpserver.example
git config --global sendemail.smtpUser myaccount

• Enfin, vous avez besoin de configurer quelques options générales de git send-email, notamment le fait d'annoter systématiquement vos patches (via annotate) ainsi que la configuration de l'encodage de vos messages:

git config --global sendemail.verify on
git config --global sendemail.annotate yes
git config --global sendemail.transferEncoding 8bit

Ok, vous êtes un contributeur externe. Vous avez réalisé quelques commits sur la branche master et vous souhaitez les soumettre au responsable du projet. Vous avez configuré git send-email comme indiqué ci-dessus.

Dans vos changements, vous avez dépassé la référence origin/master de quelques commits. Vous avez juste à lancer la commande suivante:

$ git send-email origin/master

Votre éditeur de texte configuré dans git va s'ouvrir en vous permettant d'écrire un message au début du courrier électronique. C'est là que vous remplissez la description de votre soumission de patch.

Ensuite, après l'enregistrement, git send-email vous demande une confirmation ainsi que le mot de passe du serveur SMTP (car nous ne l'avons pas renseigné en dur dans la configuration de git pour des raisons de sécurité).

Si tout se passe bien, votre courrier électronique est envoyé ! S'il y a des problèmes dans l'authentification, vérifiez votre configuration SMTP. Par exemple, dans mon cas j'utilise STARTTLS sur mon serveur SMTP et j'ai dû configurer l'option sendemail.smtpEncryption à tls pour pouvoir faire l'authentification de manière correcte.

Si vous voulez envoyer un truc différent, vous pouvez utiliser le vocable des révisions git. Par exemple, si vous souhaitez envoyer uniquement un commit précis, vous pouvez mettre son uid:

$ git send-email 1bea5dff495173beb9b93e6e0ea7df6e2435a283

Ok, vous êtes un développeur du projet et vous avez reçu un courrier électronique avec un patch dedans. Vous devez appliquer ce patch, le tester, faire d'éventuelles réponses avec l'auteur du patch puis quelques aller-retours. Néanmoins, en dehors de l'application du patch sur le dépôt, tous ces éléments se dérouleront dans votre application de courrier électronique.

Pour appliquer le patch soumis, vous devez le sauvegarder et appliquer le patch avec git am.

Dans mon cas, je sauvegarde le message au format eml depuis Roundcube dans un fichier dédié. Ensuite, je lance la simple commande:

$ git am chemin/vers/fichier.eml

Ce qui est assez intéressant, c'est que git am reprend le sujet du courrier électronique comme sujet du commit ainsi que les commentaires globaux du patch.

Il y aura forcément des conflits, des trucs pas terribles mais, comme d'habitude dans git, vous aurez besoin de gérer les choses… ou de renvoyer à l'auteur du patch, à votre discrétion.

git send-email fait les choses très bien. Après avoir passé 5 minutes à le configurer correctement et compris comment ça marchait, vous avez maintenant un outil bien intégré pour faire des propositions d'évolution sur des projets externes. Et ce, sans avoir besoin d'avoir un compte sur cette plate-forme externe, ni d'utiliser votre navigateur web pour écrire des messages. C'est plutôt efficace et en plus, tout reste dans git. Pas besoin d'outil externe.

Bien entendu, votre "pull-request" n'est pas connue du grand public par défaut. Néanmoins si l'équipe de développement a mis en place une bonne vieille mailing-list des familles, votre soumission devrait être disponible dessus. Ce n'est pas mon cas sur medspx.fr car je préfère rester dans un mode plus discret et que je n'ai pas vraiment de contributeurs externes.

Pour information, j'ai trouvé trace de git send-email sur le blog de Drew Devault, le développeur principal du projet Sway.

Je vous invite aussi à lire le guide des contributions via git send-email sur la plate-forme sr.ht. Il est plein d'exemples assez intéressants…