Hello
Il me semble que les notes ont également disparu. Cela permettait entre autre de faire le lien avec les commits en numérotation svn.
Probablement peu utilisée par la majeure partie des personnes.
Tu as un lien d’exemple d’où c’était ?
Documenté à l’époque :
Pour les notes svn, à ajouter dans le remote
fetch = +refs/svn/map:refs/notes/commits
Merci pour le signalement, je viens de vérifier et elles sont bien dans le repo sur git-lab.spip.net quand je clone depuis, donc elles ont été migrées.
1 « J'aime »
Corrigé pour les images
3 « J'aime »
Merci pour ce compte rendu.
Il aurait été le bienvenu plus tôt, mais le temps passe vite et on a tous une vie, et des limites.
Je me suis exprimé comme un connard cette nuit et j’en suis désolé.
Pardon à celleux que j’ai pu blesser.
Pour revenir sur le sujet, restent quand même ces points de friction dans la migration qui me semblent, à moi, problématiques :
Bon, ça c’est une fonctionnalité un peu « sociale », ça se remettra en route, mais on perd quand même tout l’historique sur les profils (derniers commits, derniers commentaires etc)
Et une forge, c’est aussi un endroit social, pour moi.
Ce point là me gêne beaucoup plus.
On perd toute la notion d’activité sur les dépôts : quand il a été créé, et surtout de quand date la dernière activité.
Autre point : le fait d’accepter explicitement la charte quand on crée un compte, plutôt que juste un lien que personne n’ouvrira
Et ma réponse en dessous :
Apparemment c’est prévu : Terms of Service and Privacy Policy | GitLab
Est ce qu’on peut mettre ça en place, avec quelque chose d’un peu moins charabia que :
Et pour ce point là :
Mais dans le cas d’une connexion avec un compte Github / Gitlab.com ?
Est ce qu’on accepte la connexion de comptes directement depuis Gihub/Gitlab, qui n’auraient donc pas lu / coché l’acceptation de la charte ?
Il me semble qu’on l’avait bloqué avec Gitea.
Ça me parait un point important et identitaire de SPIP aussi.
On n’est pas juste un dépôt de code source derrière git.
On est quand même une organisation (même si elle est anarchiste, ce que je revendique), avec son histoire et sa politique, qui veut se protéger de certains comportements (les mascus anti-inclusifs, au hasard).
Je n’avais pas trouvé dans les paramètres en tout cas. Même en suivant le lien que tu indiquais que j’avais vu également.
Tu ne peux pas te connecter via Github ou Gitlab.com sans avoir créé et validé ton compte préalablement (et activer l’une ou l’autre ou les 2 de ces authentifications dans tes préférences).
Il y a probablement d’autres moyen de ré indiquer la charte aussi ; j’ai vu qu’on peut aussi définir un message dans le pied de page par exemple.
Sans minorer l’utilité de cette page (« activité »), sur notre instance Gitea, l’activité conservée ne semble être que de 1 an (sur une histoire qui peut remonter à presque 25 ans pour certain dépôt). Je suppose que c’est purgé à dessein.
Ah oui, je n’avais pas vu que c’était limité à 1 an.
Dans ce cas on peut s’en passer, c’est de moindre importance en effet.
1 « J'aime »
Coté gitea, de ce que je vois l’affichage proposé est limité à 1 an max mais pas de purge. Ceci pour des raisons de performances, il y a un ticket pour autoriser la personnalisation des intervalles de temps
1 « J'aime »
Ce point là est corrigé, après l’import, on réécrit dans la base de données (table projects) les différentes dates issues du Gitea (date de création & de mise à jour), et ça semble suffisant !
2 « J'aime »
Notons qu’on met la date que retourne Gitea, mais parfois elle a une date de mise à jour récente qui ne semble pas correspondre à une opération sur le projet (commit, commentaire, PR, tag…)… mais bon, c’est pas grave, c’était comme ça là bas aussi donc…
Par exemple sur spip-contrib-extensions/mejs - mejs - SPIP on GIT (aucune activité récente), l’api https://git.spip.net/api/v1/repos/spip-contrib-extensions/mejs indique une date de modification updated_at "2023-06-26T15:53:11+02:00" sans trop savoir à quoi cette information correspond exactement.
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.
1 « J'aime »
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 ?
1 « J'aime »
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 inscription
- elle aussi rappelée en pied de page ; vraiment utile ?
Je 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…