Ma vie sans GitHub - partie 2: git send-email đź”—

Posted by MĂ©dĂ©ric Ribreux 🗓 In blog/Code/

#code #git #decentralized #dev

Introduction

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 !

Comment ça marche ?

Globalement le mode opératoire est assez simple:

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).

Quelques éléments de configuration

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.

git config --local sendemail.to project@thesuperproject.example
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
git config --global sendemail.verify on
git config --global sendemail.annotate yes
git config --global sendemail.transferEncoding 8bit

Un exemple concret

Du point de vue du contributeur externe

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

Du point de vue du développeur interne

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.

Conclusions

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…