Carnet Wiki

Proposer un patch via git.spip.net pour le noyau ou la dist (pull request)

Cet article présente les informations et étapes permettant de se servir des dépots git.spip.net pour proposer un patch (une ’PR’ pull request) pour le noyau de SPIP et pour les plugins-dist.

Pour l’instant, seule la solution passant par l’UI en ligne (gitea pour git.spip.net) a été détaillée, par JLuc initialement, puis par Cerdic, avec de menues différences.

TODO : tester les petites différences entre les soluces et fusionner. Détailler les étapes au besoin.

Liste des repos

-  le core de SPIP : https://git.spip.net/spip/spip

-  les plugins-dist sont dans le dossier https://git.spip.net/spip et il y a un repo par plugin.
Par exemple : https://git.spip.net/spip/organiseur

Le script https://git.spip.net/spip-contrib-outils/git_loader/src/branch/master/git_loader.sh permet de cloner le core et les plugins-dist pour avoir un site fonctionnel (Maieul : « ça marche »)
Alternativement le script svn ://zone.spip.org/spip-zone/_outils_/checkout.php permet également d’installer (ou de mettre à jour) un SPIP + plugins-dist avec la commande :

checkout.php spip -bmaster repertoire_destination

ou l’argument -b précise la version de SPIP à installer (« master » ou « spip-3.2 »)

En bref par marcimat

Si Franky veut proposer une PR sur le plugin-dist media :
-  forker le repo (SPIP/medias => franky/medias),
-  le cloner chez toi (git clone ....)
-  te mettre dans une branche nouvelle (git checkout -b ma_nouvelle_branche),
-  modifier les fichiers de la librairie, tester et commiter (git add . ; git commit ...)
-  pusher sur ton repo (git push ; ou git push —set-upstream origin master)
-  ensuite une fois la branche envoyée, c’est sur l’interface graphique ! sur francky/medias tu dois pouvoir dire que tu proposes une PR via l’interface graphique : Demande d’ajout :
sur le 2è select, (tirer les modifications DEPUIS ...) mettre ta branche
avec un titre et un texte
-  + et si tu veux reporter dans les autres versions (d’autres branches de SPIP) ?
c’est avec d’autres PR car une PR ne peut aller que sur 1 destination. Cependant dans ce cas, c’est juste 1 commit, tu pourrais le cherry-picker et le pousser directement dans les autres branches par exemple (si c’est exactement le même code qui change)..

Soluce par Cerdic

La bonne méthode c’est en effet toujours de faire une branche pour une PR, en repartant du dernier état du master source.

Par exemple, si origin est ton propre repo, et officiel est le repo officiel SPIP (les deux remote), tu vas faire quelque chose comme :

-  Récupérer les sources à jour depuis officiel :
git fetch officiel

-  Checkout la dernière version du master du repo officiel :
git checkout officiel/master

-  Créer ta branche de travail à partir de là :
git checkout -b ma-super-proposition

-  Faire les modifs et commit

-  Quand c’est finis, tu push sur ton repo :
git push origin ma-super-proposition

-  Là tu n’a plus qu’à aller sur l’interface web et cliquer sur « Proposer une PR » à partir de cette branche.
La PR sera propre car ne comportant que les commits proposés et directement mergeable, ce qui en facilite le traitement et le merge dans le repo officiel.

Explication initiale par JLuc

Ces indications sont légèrement différentes de celles de cerdic, mais suivent la même piste.

Cloner le repo sur git.spip.net

Via l’UI gitea (bouton "bifurcation" ou "fork"). Si votre pseudo est monpseudo, cela crée un repo https://git.spip.net/monpseudo/spip ou https://git.spip.net/monpseudo/organiseur

Cloner localement le repo

Cloner localement votre clone distant.

Pour le core :

git clone https://git.spip.net/monpseudo/spip.git

Pour un plugin, par exemple :

git clone https://git.spip.net/monpseudo/organiseur.git

Brancher localement
La branche servira à faire la modif proposée sur une base propre et qui ne servira que pour ce patch.

git branch ma_modif

se mettre sur la branche

git checkout ma_modif

Créer la branche sur votre repo distant en la reliant à sa version locale

git push --set-upstream monpseudo ma_modif

Editer les fichiers
Faire vos modifs dans les fichiers

Commiter et pusher

Commiter toutes vos modifs sur cette branche (locale) :

git commit -am "un joli message de log"

Reporter sur votre repo distant :

git push

Proposer le patch aux repos SPIP

Via l’UI gitea : dans l’onglet « Demandes d’ajout » de votre repo cloné distant, cliquez « Nouvelle demande d’ajout ».
-  Dans le 1er select, laissez la destination « SPIP:master ».
-  Dans le 2e select, choisissez la branche d’origine : « monpseudo:ma_modif »
-  Vérifiez le message de commit et validez avec « Créez une demande d’ajout »
Voilà. Votre proposition se retrouve sur https://git.spip.net/SPIP/spip/pulls

Pour github c’est presque pareil : https://help.github.com/en/articles/creating-a-pull-request

La prochaine fois

Si vous devez améliorer votre patch, restez sur cette branche ou revenez y :
git checkout ma_modif

Synchronisez votre dépot avec les devs SPIP (master).

-  Q : quelle commande ?

(vérifier : git pull)

Contextualisation, par azerty

Pour compléter, une PR (pull request) ne peut se faire que de branche à branche. Dans une PR on propose un ensemble de corrections présentes dans une branche à appliquer sur une autre branche.

Pour qu’une PR soit prise en compte il faut que la branche cible (celle qui doit recevoir les correctifs) ait connaissance de la branche source (celle contenant les correctifs). Comme le PR est géré par la forge, ces 2 branches doivent être présentes sur la dite forge. Pour ceci il y a plusieurs façon de procéder :
-  Avoir un seul dépôt et 2 branches
-  Avoir un dépôt , son fork (une copie) et 1 branche distincte par dépôt

Comme indiqué juste avant la branche cible doit avoir connaissance de la branche source, par conséquent une branche présente uniquement sur un clone local ne peut fonctionner. Il faut impérativement que la branche soit poussée sur la forge. La création d’un PR via interface web cache certaines de ces étapes. En général le fork, le clone local (sur le serveur) et la création de la branche se fait à la volée. Pour ma part c’est une voie à éviter car elle cache trop de choses pour être compréhensible quand a besoin de proposer un patch plus complet.

Remarque : Lorsqu’on pousse une branche sur la forge, gitea communique le lien permettant de convertir la branche en PR.

Énumération des objets: 50, fait.
Décompte des objets: 100% (50/50), fait.
Compression par delta en utilisant jusqu'à 4 fils d'exécution
Compression des objets: 100% (32/32), fait.
Écriture des objets: 100% (38/38), 3.22 KiB | 3.22 MiB/s, fait.
Total 38 (delta 26), réutilisés 0 (delta 0)
remote:
remote: Create a new pull request for 'Monpatch':
remote:   https://git.spip.net/Organisation/Projet/compare/master...Monpatch
remote:
To git.spip.net:Organisation/Projet.git
   f214ce3..e781404  Monpatch -> Monpatch

Proposer un PR en ligne de commande

Passer par l’interface Web comme il est décrit plus haut ne devrait être utilisé que dans les cas simple comme la correction d’un faute de typo. Dans le cas général, la solution recommandée est d’utiliser une copie locale du dépôt GIT.

Sinon, voir https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork

En vidéo et avec plein de lignes de commande

JLuc - Mise à jour :11 février 2022 à 18h11min