[spip-dev] Proposer-un-patch-via-git

Dev
1

Les premiers de cordée, semble t il, préparent la migration vers composer...

Je trouve l'évolution avec git assez excitante
mais au delà d'un petit fonctionnement tranquille entre moi et moi-même,
c'est pas évident quand il y a des conflits
ou des PR à faire sur un repo où je n'ai pas le droit d'écrire.

POUR PROPOSER UN PATCH POUR LA DIST

Avec SVN, c'est basiquement simple (et peu sympa) :
il faut générer localement un fichier .diff ou .patch et le joindre au ticket sur core.spip.net

Avec git, c'est plus sympa car on peut proposer plus directement une modification :
via une PR qui pourra être retouchée et améliorée par le même procédé,
et qui, lorsqu'elle sera acceptée, sera intégrée en un clic au repo maître.

C'est plus sympa mais ça nécessite une mise en place d'un tout autre ordre
a propos de laquelle j'ai commencé une documentation / pris des notes :
https://contrib.spip.net/Proposer-un-patch-via-git-spip-net

J'y décris en détail la manière de faire pour git.spip.net.

J'y recommande de créer une branche pour chaque modif proposée,
car mon expérience c'est que sinon, les modifs s'ajoutent et se mélangent
et ça devient sale et difficile à utiliser.

Je décris comment faire en passant par l'interface en ligne
- ce qui nécessite de faire un clone en ligne et de cloner localement ce clone -
car ça permet de faire la PR finale via l'UI,
-- et car je ne sais pas faire la PR finale par la ligne de commande.

Ce serait toutefois plus simple de faire la PR localement via la ligne de commande,
et sans nécessiter la création d'un clone sur git.spip.

Est-ce que quelqu'un pourrait expliquer quelle est cette commande ?

JL

2

Bravo JLuc,
Tu continues a écrire plein d'informations hyper-utiles sur Contrib :
bravo, et merci !
Je persiste à regretter que ces informations (et plus généralement
toutes celles de Carnet) ne soient pas accessibles dans le moteur de
recherche principal de Contrib, et j'espère que l'arrivée de nouveaux
modes de recherche, avec mots-clés, statuts... pourra aussi proposer
"avec Carnet" comme "avec Archives".
D'ailleurs, j'aimerais bien proposer de regrouper tous ces articles
"autour de la vie des dépots" dans une rubrique dédiée (dans Carnet
aujourd'hui et à terme dans.... pour donner une vue générale et
actualisée des moyens et outils pour collaborer a SPIP ; rien que mon
expérience en ce domaine est extremement décourageante, car il (me)
reste tres difficile de comprendre les tenants et aboutissants des
divers lieux de dépots, stocjkages, techniques, et avec le passage
envisagé de SVN à GIT (voire Composer par-dessus SVP), c'est totalement
abscons ...

Si cette approche te sied, j'aimerai y contribuer, en jouant le "candide" !
@+
YannX

PS Maieul, qui gère le Carnet (en termes de sous-rubricage en
particulier...)

3

Le carnet, c'est un carnet… de notes. Toutes plus inégales les unes que
les autres (certains trucs très avancés, d'autres très très brouillon).
Donc on ne peut pas mettre ça au même niveau que du vrai contenu relu.

Plus précisément, en ce qui concerne cette doc de JLuc, il s'agit de
documenter comment contribuer *au noyau*.

À partir du moment où ce contenu est finalisé, il n'y a aucune raison
que ça reste dans le carnet, et même pas sur Contrib. En effet, il y a
déjà une rubrique officielle du site central qui est là pour contenir
comment contribuer à SPIP :
https://www.spip.net/fr_rubrique205.html

C'est ici que cette doc devrait être (et tenue à jour si on change pour
Github ensuite, etc).

4

Hello,

tu ne peux pas faire de PR en ligne de commande, c’est une fonctionnalité propre aux forges (a moins que je me trompe)

En tout cas la bonne méthode c’est en effet toujours de faire une branche pour une PR, en repartant du dernier etat 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 derniere 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

… tu fais tes modifs et tu commits
Quand c’est finis, tu push sur ton repo :

git push origin ma-super-proposition

et là en effet 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.

Cédric

5

je préciserai deux choses:
- certaines forges envoient directement l'URL pour faire un PR lorsqu'on push une branche (github, gitlab)
- en general plutot que "officiel" on utilise "upstream".

6

Bonjour

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

En espérant ne pas avoir ajouter du bruit à tout ça.

Km