Salut,
comment ça se passe pour intégrer des repo persos dans la forge commune ? J'ai cru comprendre qu'on pouvait, depuis GitLab, conserver l'historique des commits et tout...
Mon repo : https://gitlab.com/jmoupah/html5up_forty
Et plus généralement, comment on fait pour créer un repo sur la forge ? On peut le faire par le bouton create ou il y a un "protocole" ?
jean marieSalut,
comment ça se passe pour intégrer des repo persos dans la forge commune ? J'ai cru comprendre qu'on pouvait, depuis GitLab, conserver l'historique des commits et tout...
Mon repo : https://gitlab.com/jmoupah/html5up_forty
C'est pas depuis gitlab, c'est depuis git. Le principe de git est chaque repo, qu'il soit distant ou local, possède un historique, et qu'on peut synchroniser les historiques entre les repos
Pour ton besoin, et pour faire court (il y a d'autres méthodes bien sûr)
1. Tu clone en local ton repo
2. Tu crée un autre repos distant
3. Tu le référence dans ton repos local avec git remote add <unnomdetonchoix> <lurldureposdistant>
4. Tu fait git push <unnomdetonchoix>
<unnomdetonchoix> correspond au nom qui permet de référencer depuis ton repos local un repos distant.
par convention, lorsqu'on clone une depot distant, il est référencé avec le nom origin comme dépot local. Mais tu peux en référencer plusieurs.
Une pratique courante est
1) upstream pour désigner le repos communautaire/officiel du projet
2) origin pour designer le repos distant "personnel"
Tout dépend en fait si tu veux garder ou pas ton repos distant perso.
Si jamais tu ne souhaite plus garder qu'un seul dépot distant comme depot de reférence, tu peux aussi simplement modifier l'url
git remote set-url origin <lurl du repos disttant>
Et plus généralement, comment on fait pour créer un repo sur la forge ? On peut le faire par le bouton create ou il y a un "protocole" ?
j'ai cru comprendre que c'était désormais possible (cf mail de camille sur la mise à jour de gitea. par contre je ne sais pas si cela syncrhonise automatiquement avec la zone, j'ai cru comprendre qu'il fallait encore une intervention humaine, pour l'instant
Hello,
Salut,
comment ça se passe pour intégrer des repo persos dans la forge commune
? J’ai cru comprendre qu’on pouvait, depuis GitLab, conserver
l’historique des commits et tout…
Mon repo : https://gitlab.com/jmoupah/html5up_forty
C’est pas depuis gitlab, c’est depuis git. Le principe de git est chaque
repo, qu’il soit distant ou local, possède un historique, et qu’on peut
synchroniser les historiques entre les reposPour ton besoin, et pour faire court (il y a d’autres méthodes bien sûr)
- Tu clone en local ton repo
- Tu crée un autre repos distant
- Tu le référence dans ton repos local avec git remote add
- Tu fait git push
correspond au nom qui permet de référencer depuis ton
repos local un repos distant.
En fait pour migrer d’un github ou gitlab vers la forge Gitea de SPIP il existe une opération qui s’appelle « Nouvelle migration » disponible à coté de son avatar.
Elle permet en un seul formulaire de transférer un repo github ou autre vers ton organisation personnelle sur la forge et même dans une des organisation spip-contrib*.
C’est donc à préférer car plus simple.
Et plus généralement, comment on fait pour créer un repo sur la forge ?
On peut le faire par le bouton create ou il y a un « protocole » ?j’ai cru comprendre que c’était désormais possible (cf mail de camille
sur la mise à jour de gitea. par contre je ne sais pas si cela
syncrhonise automatiquement avec la zone, j’ai cru comprendre qu’il
fallait encore une intervention humaine, pour l’instant
Comme l’a dit Camille c’est ouvert.
Maintenant je pense qu’il faudrait quand même que pour le moment on communique avant le temps que tout soit cadré.
En outre, que ce soit une migration ou une création de repo, ces opérations n’agissent que sur le Git.
Aucun repo ne sera créé ni synchronisé automatiquement sur la zone SVN.
Donc il me semble que tant que tous ces processus ne sont pas définis et écrits le mieux est de communiquer ce qu’on fait avant de le faire et permettre ainsi de faire les opérations manuelles si besoin au fil de l’eau.
Salut,
Salut,
J’ai fait cette manip pour un plungin (microedition) qui vient de framagit.
Bonjour
J'ai lancé la migration il y a plus d'1h, c'est toujours en cours, je ne
sais pas si c'est normal
:spip-contrib-squelettes / html5up_forty · GitLab
De ton coté cela semble bon, je vais regarder l'historique serveur
pour voir si un truc coince ou si c'est juste qu'il faut attendre.
ça m'a demandé les identifiants / mots de passe du repo source mais
comme il est public, j'ai rien indiqué, ça vient peut-être de là ?
Il n'est pas obligé de saisir ses identifiants, cela est utile dans le
cas du transfert des tickets, PR et autres services des forges.
J'ai fait cette manip pour un plungin (microedition) qui vient de framagit.
Vérifier que le mail sur le dépôt source et le dépôt git.spip soit le même.
Cela n'est pas obligatoire, c'est juste pour permettre à la forge
d'associer la même personne si celle ci posséde plusieurs courriel.
Il est possible d'ajouter des courriels secondaires dans ce cas via la
gestion de son profil.
Nouvelle Migration depuis git.spip
Aller dans les paramètres du dépôt fraîchement migré > changer le propriétaire et y mettre l'orga spip-contrib-squelettes.
Cela n'est plus valide car on peut dès la migration ciblé
l'organisation. Corrigé depuis la dernière mise à jour de gitea.
Attention on perd la main après ça, par exemple je n'ai plus accès aux réglages du plugin désormais. Mais c'est pas très grave puisque c'est un miroir. et que je mets continue à mettre à jour sur framagit (la maj se fait sur git.spip après un certain délai, normal)
Cela n'est plus vrai. Lors d'une migration la personne ayant fait
l'opération obtiendra aussi des droits d'administration sur le dépot
fraichement migré (peu importe l'organisation cible)
Km
Attention on perd la main après ça, par exemple je n’ai plus accès aux réglages du plugin désormais. Mais c’est pas très grave puisque c’est un miroir. et que je mets continue à mettre à jour sur framagit (la maj se fait sur git.spip après un certain délai, normal)
Cela n’est plus vrai. Lors d’une migration la personne ayant fait
l’opération obtiendra aussi des droits d’administration sur le dépot
fraichement migré (peu importe l’organisation cible)
Ah ça ne semble pas être mon cas (dépôt microedition), où alors je vois pas où je pourrais intervenir (peut-être parce que j’ai fait ça, ou mal fait, avant la mise à jour)
Fa_b
Humm,
Il me semble que tu n’as pas fait une migration mais un miroir sur Gitea de ton repo Framagit.
Et ça ne date pas d’aujourd’hui mais d’une semaine non ?
Donc on ne parle donc pas de la même chose a priori.
Si tu “migres” c’est pour abandonner ton repo sur le git source de mon point de vue.
Je l’ai fait pour deux plugins que j’avais sur Github que j’ai passé en archive dans la foulée et Jean marie aussi et tout fonctionne comme Camille l’a expliqué.
Et bien je ne souviens plus si j’ai coché miroir ou pas, mais puisque je n’ai plus accès à l’admin du plugin sous gitea impossible de le savoir.
Si je te le dis c’est que je le sais.
En tant qu’admin j’ai accès à toute la configuration de ton repo.
La question c’est que veux-tu en faire : toujours un miroir ou passer sous gitea ?
Ok pour le passer en gitea, je brancherai mon dépôt local dessus (et ferai l’inverse sous framagit, cad le passer en miroir, c’est pratique d’avoir une vue globale de tous ses dépôts quelque part).
Merci.
Hello,
Saulut
Je pense qu'il y a un problème en effet 
Je suis en train de regarder et d'identifier la cause (gitea, réseau,
gitlan, magie noire, ....)
Ne fais rien dans l'immédiat.
Merci
Km
Ça marche, j'attends ton retour pour relancer la manip.
En attendant, je commit sur mon repo.
jeanmarieSalut Camille,
j'ai un 2nd import à faire à partir d'un repo Framagit (au lieu de Gitlab pour le 1er essai infructueux). Est-ce qu'on retente le coup ou c'est trop tôt ?
Et, question subsidiaire, comment ça se passe pour un changement de version majeure, on fait une branche ? Si oui, comment on fait pour que la nouvelle branche soit la principale et que l'ancienne passe en legacy/archive ?
Bref, c'est quoi les bonnes pratiques sur git
jean marieDonne l’adresse de ton repo je vais le migrer.
Je ne vois pas pourquoi il faudrait attendre si c’est un autre repo que celui qui a merdé.
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 ?
Donne l'adresse de ton repo je vais le migrer.
Je ne vois pas pourquoi il faudrait attendre si c'est un autre repo que celui qui a merdé.
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 : L0r3nt / hyperspace_theme_responsive_pour_spip · GitLab
(en accord avec l'auteur HTML5UP Hyperspace V2 - SPIP-Contrib )
Idéalement le nommer html5up_hyperspace pour être cohérent avec les autres.
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)
jean marie
Yop,
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.
Salut
J'ai purgé le repo. J'ai réimporté en mode miroir
https://git.spip.net/spip-contrib-squelettes/html5up_forty/
Tu es admin sur ce dépot.
Km
Super, merci !
Par contre, au moment du pusher sur git.spip.net, j’ai cette erreur: Git : remote : mirror repository is read-only.
Je dois faire qqch sur mon repo ? J’ai regardé la doc mais je ne suis pas sûr de bien saisir le miroir, dans quel sens ça va, push/pull (j’ai configuré en Push car pull n’est pas dispo dans l’offre gratuite). J’ai également ajouté mes identifiant / mot de passe sur le repo git.spip.net (Autorisations de clonage), mais pas mieux…
Si besoin, on peut tout rapatrier sur git.spip.net et je ferme mon repo, hein…
jean marie