Ce que je pense avoir compris en pur git, c’est qu’il n’y a que le commit qui enregistre une date dans un dépôt. Créer une branche, ou apposer un tag, en soit, n’affecte pas l’historique puisque ces opérations sont basées sur un commit.
J’imagine que les autres opérations qui changent la date sur une plate-forme, quelle qu’elle soit, sont enregistrées dans une base de données et que son API fait le mix.
J’essaie un petit point
Gitlab en français Les images présentes Date des dépots corrects Refs svn récupérées dans le .git Relation fork <> projet forké Valider la charte à la première connexion de comptes pré-existants
Migration des projets de spip-galaxie (il y aura une modification temporaire à faire pour leur migration, car Gitlab n’aime pas migrer des projets contenant des . dans le nom)
La barrenav est mal placée sur le formulaire de réinit de mot de passe
: Forcer à valider la charte à l’inscription de nouveaux comptes. Il y a une validation tacite indiquée à l’inscription, mais pas de représentation ensuite de la charte à valider. Bien indiquer la charte à la connexion ou inscription
Recherche globale sur l’ensemble du code. Effectivement ce n’est pas disponible dans l’édition communautaire de Gitlab. On a testé en passant un autre outil CodeSearch de SourceGraph qui n’est pas libre, dont le résultat est vraiment impressionnant, mais limité à 10 utilisateurs identifiés dans sa version gratuite (l’empreinte processeur bien visible aussi). Activité des utilisatrices & utilisateurs : effectivement, Gitlab ne la recrée pas lors de la migration. Il conserve ensuite 3 ans d’activité avant de purger.Voyez vous d’autres choses à noter ?
Je viens de vérifier (même identifié), et je trouve uniquement une recherche de code par projet là bas, pas par groupe ; tu es certain de toi ?
Par ailleurs j’ai vu que la page d’inscription a un bloc latéral qui présente aussi la charte
Sign up · GitLab d’une façon plus présente et sympa
Ah bah voilà ! Y a la même chose maintenant, à la fois sur sign_in et sur sign_up !
Bien indiquer la charte à la connexion ou inscriptionJe viens de re vérifier aussi, je confirme que je disais du caca, j’ai du rêver, my bad.
Recherche globale sur l’ensemble du code.
franchement, c’est un usage plutot rare, et au pire bah il y a gitea_mirror et une recherche en local.
Euh… moi, je trouvais ça extrêment pratique, que ce soit sur github.com ou sur une instance gitea. Tant pis.
Et je ne vois pas l’intérêt dans la démarche d’une migration vers une instance gitlab de conserver des miroirs sur une autre instance gitea…
Lapin compris… ^^
à moins que « gitea+mirror », ça signifie autre chose, ça présuppose qu’on maintiendra des miroirs git depuis la future instance gitlab vers une instance gitea… et je n’en vois pas l’intérêt, sinon une charge supplémentaire de monitoring, d’exploitation et de ressources matérielles… Ou alors, quelque chose m’a échappé 
Nan c’est un script qui clone en local tous les dépôts de la zone et les maintient à jour (juste en git, pas dans une forge). Et oui j’utilise ça aussi pour faire de la recherche de code en local du coup dans le corpus de la zone.
Ok… ça devrait s’appeler git_clone_all 
Et bien, c’est ce que je préfères éviter de faire.
Cloner dans les … 2000 dépôts git, je trouve ça très « époque svn » et pas très écolo ^^
Mais encore une fois, tant pis hein.
Est ce utile ou pas ? De l’usage que j’ai pu voir c’est assez utile pour savoir quel plugin ou quel bout de code implémente un fonctionnalité ou un besoin sans savoir d’avance ce que tu recherches.
Mais en effet au vu des retours présents, ça semble d’un intérêt mineur, ce n’est clairement pas à considérer comme une regression.
En effet c’est idiot, si on fait du miroir c’est soit pour de la visibilité à la github ou du PRA à la gitlab. Gitea sort complément de l’histoire.
Parfait on va pouvoir solder cette histoire dans les prochains jours.
De mon coté j’aimerai couper le service pour à la fin du mois.
Pour que tout le monde puisse s’organiser, j’avais plutôt pensé attendre le weekend du 1/2/3 mars, car la migration va nécessiter de couper les cles SSH (pour que personne envoie du code) et les accès à la forge (pour que personne envoie des ticket et commentaire), pendant tout le process de migration qui est scripté (mais long). Donc ce serait après la fin du mois…
Maintenant si tu nous dit que tu éteint la lumière le 29/02, je peux aussi lancer la migration maintenant, mais ceux qui avaient prévu de faire des trucs ce weekend vont être un peu le bec dans l’eau. Dis nous tes contraintes…
Je me permets de pinger @maieul : pour les formations que tu proposes, l’accès à la forge est-il nécessaire ?
Ok
c’est sur que cela serait utile, mais pas indispensable non plus, a priori. Cela étant si on part sur les dates de @cerdic pour le moment de la migration, il n’y pas de raison que cela pose problème car cela ne se combinerait pas avec les dates des formations
@JamesRezo on est d’accord que ni le terme gitea_mirror ni le principe lui meme n’est idéal. Mais faute de mieux pour l’instant. Cela étant l’usage pour moi c’est en gros moins d’1/fois ans.
parmis les points importants à cours terme : quid du debardeur?
on va le reconnecter sur le gitlab post migration. Le débardeur est déjà prévu pour utiliser des api différentes, il suffit qu’on ajoute un connecteur gitlab ici debardeur/connecteur at master - debardeur - SPIP on GIT pour implémenter les 2 ou 3 fonctions nécessaires et ça devrait rouler…
Hello,
Une bonne nouvelle pour le dépôt composer de SPIP !
Je viens de (re)tester et valider le combo satis/gitlab et il sera donc possible de référencer les zip générés par la plate-forme Gitlab dans notre dépôt composer. Il ne sera alors plus nécessaire de générer les zips comme nous le faisions avec Gitea.
Cela signifie que la montée en charge du dépôt composer est envisageable bien plus sereinement que jusqu’alors.
Après la migration de ce week-end, je mettrai en place la config coté satis et gitlab pour les packages qui sont déjà référencés. Et on verra plus tard pour la suite…
Ah, dans le genre rattrapage aux branches, je vois qu’on a des URLs de la forme https://core.spip.net/attachments/download/717/Capture%20d_écran%202015-05-03%20à%2023.14.12.png
dans des issues ou commentaires, comme ici #2915 - dans privé en colonne gauche dans h3, chevauchement texte sur lien "plus d'info" - spip - SPIP on GIT
C’est l’ancien dossier des pièces jointes/copies d’écran du redmine je pense. @azerttyu on l’a encore quelque part ? ou @cy_altern ? Si on l’a encore je veux bien récupérer un zip de ce dossier attachments/download pour qu’on puisse continuer à voir les anciennes copies d’écran…
