Version 9 — Septembre 2019 — JLuc
Cet article présente les informations et étapes permettant de se servir des dépots git.spip.net pour proposer un patch 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 quelques différences.TODO : préciser la soluce cerdic, tester les différences, fusionner et détailler les étapes.
TODO : préciser la soluce cerdic, tester les différences, fusionner et détailler les étapes.
- le core de SPIP : https://git.spip.net/SPIP/spip/
- les plugins-dist sont dans le dossier https://git.spip.net/dist et il y a un repo par plugin.
Par exemple : https://git.spip.net/dist/organiseur
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.
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 (delta )
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
Ces indications sont
Cloner le repo sur git .spip.net
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
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
)
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.