Re: Import d'un repo perso dans la forge SPIP

Yop,

Le lun. 10 févr. 2020 à 13:18, Jean Marie Grall <
[email protected]> a écrit :

> D'après les retours de Camille, le problème ne semblait pas venir du repo
> mais de la forge, donc je posais la question.
>
> Le repo :
> https://framagit.org/L0r3nt/hyperspace_theme_responsive_pour_spip.git
> (en accord avec l'auteur
> https://contrib.spip.net/Hyperspace-squelette-responsive#comment503969-502739
> )
>
> Idéalement le nommer html5up_hyperspace pour être cohérent avec les autres.
>
C'est fait, tu as le dépot a priori nickel avec deux branches master et
dev, et des tags.



> Tu crées une branche v1 qui va être ton "archive" et la branche master va
> continuer à porter la version courante. Je ne vois pas trop ce qui te gêne ?
>
> Rien ne me gêne, je suis juste moins coutumier de git, donc je pose la
> question.
>
> Pour les plugins déjà sur la zone (le cas d'autres plugins), ça pose la
> question de la structure version/trunk sur SVN et du branchement car, tant
> que le plugin est en dev, il n'est pas souhaitable de le distribuer.
>
> Donc est-ce que la solution est de créer une branche +1 le temps du dev
> (qui n'est pas distribuée donc) puis, quand finalisée, passer la version
> courante en branche et merger la version +1 dans le master ? (c'est ce qui
> semble en cours pour la V4 d'agenda)
>
Pour moi ça dépend de ce que tu fais.
Si tu crées une nouvelle version incompatible alors là oui une branche se
justifie. Donc tu vas créer un branche v0 ou v1 pour stocker ta branche
actuelle et juste corriger les bugs et tu bosses ta nouvelle version dans
la master. Par contre, tu distribues la v1 dans SVP. Moi je ferais comme ça
mais on peut aussi voir les choses en sens inverse.
De toute façon le but n'est pas dans ce cas de merger les branches in fine.

Maintenant si tu veux juste distribuer ta version master dans son état
actuel sans prendre en compte tes modifications à venir qui restent
compatibles mais qui peuvent amener leur lot de bugs temporairement, alors
tu fais un tag que tu distribueq et tu continues à développer dans ta
branche master.
C'est d'ailleurs ce qui est toujours recommandé.

Le souci pour toi avec ce nouveau plugin sur Git c'est qu'il n'est pas sur
la zone SVN et donc ne peut pas être ajouté à archivelist (Camille tu
confirmes ?).
Donc pour le distribuer il faut passer par un external sinon qui lui
demande un tag !
Je ne sais plus très bien où on en est sur le sujet de smart-paquet en git,
faudrait que Camille ou Cédric confirment ou pas ce que je dis.

++
Eric