Vieux tags réapparus sur spip/spip

Des vieux tags (spip-x.y.z) sont réapparus sur le projet spip/spip (quelque part entre le 28 juin et le 4 juillet), sans avoir trouvé spécialement l’origine de leur retour d’ailleurs (on n’a pas trop cherché non plus).

Rappel : pensez à enlever les éléments (tags / branches) supprimés du serveur sur vos repository locaux (git fetch --prune --prune-tags) afin d’éviter de pousser ensuite de vieux éléments par erreur (notamment et particulièrement ces vieux tags).

Bref, je viens de les re-supprimer.

1 « J'aime »

Merci @marcimat

J’avais remarqué ça et signalé le pb sur IRC ces derniers jours, merci pour le ménage :slight_smile:

Effectivement, tu as dit ça le 4 juillet à 14h57… ce qui finalement ne nous apprends rien de plus pour le moment :stuck_out_tongue:

Je sais pas trop comment on pourrait voir ce qui s’est passé, à part avec un reflog sur le serveur git peut être… mais y a pas eu de notifications de shiraz semblerait il en tout cas.

J’ai aussi vu que ces vieux tags sont restés sur les miroirs (github, gitlab)

Rah mais crotte !

Depuis git.spip.net:spip/spip
   c8fd73f26..a1183007d  master            -> origin/master
   0d9194943..34e7fb89b  4.1               -> origin/4.1
 * [nouvelle branche]    issue_4832        -> origin/issue_4832
 * [nouvelle étiquette]  spip-1.8.3b       -> spip-1.8.3b
...

Ils sont revenus ?!?!

Est-ce un bug introduit avec une mise à jour de Gitea peut être ?

Je vois que les forks indiquent « 0 Tag » en onglet, et ne les listent pas (tel que ici https://git.spip.net/RealET/spip/tags) alors qu’ils sont bien présents dans le dépôt du fork (notamment les vieux tags justement https://git.spip.net/RealET/spip/src/tag/spip-1.8.3b) (RealET dit avoir forké il y a 1 mois environ). Cela pourrait correspondre au ticket https://github.com/go-gitea/gitea/issues/19622 chez Gitea, ou https://github.com/go-gitea/gitea/issues/18715 corrigé en 1.16.2

Cependant je ne vois pas de ticket chez Gitea qui indiquerait la création de tags sous certaines circonstances (PR, mirroir, …)

Sur https://github.com/go-gitea/gitea/issues/19622#issuecomment-1119176063 on peut lire à propos des tags listés dans le menu déroulant :

Those tags are loaded directly from git repo. The tags in the header are loaded from the database(which should be updated on a push with tags). Does try.gitea.io have too many pushes in it’s queue? From my perspective it doesn’t seems like a bug because I cannot reproduce it locally.

Il semble donc que le problème ne soit pas dans la base de gitea mais dans le repo, reste à trouver ce qui fait ressortir ces tags sur le repo. Je pensais avoir un accès à la machine de git.spip.net, mais on dirait bien que non, @cy_altern ou @azerttyu pourront certainement nous en dire plus avec un reflog.

Hello

git reflog n’est pas utile dans ce cas. On n’aura pas de vue sur les tags actifs.

git@vailopaa:~/repositories/spip/spip.git# git tag -l |grep 1.8   
spip-1.8.3b
spip-2.1.8
spip-3.1.8
v1.8.3+b
v2.1.8
v3.1.8

Hello

J’ai fait mon naturel. J’ai supprimé directement sur le dépot les tags
git tag |grep "^spip-.*$" | xargs -n 1 -i% git tag -d %

Gitea semble raccord avec ce changement

En complément j’ai modifié le cron qui met à jour le dépot github avec un --mirror et --prune.
Il est possible que cela n’était synchronisé auparavant. Sachant que c’était un push simple jusqu’à présent.

1 « J'aime »

Bon, en plus de cette réapparition de tags l’autre jour, on avait manifestement perdu ~ 14 commits reportés sur SPIP 4.1, et on s’en aperçoit en voulant faire la release…

La branche 4.1 est passée à un moment de 01 juin au 28 juin, en zappant les commits intermédiaires qu’elle avait reçue.

  • c79034a5a 2022-06-01 - fix(#5190): On peut avoir plusieurs adresses …
  • 86a9705b4 2022-06-28 - fix: Type de paramètre sur l’appel de controles_md5

C’est aussi vers ce moment là (28 juin) qu’on pense que les vieux tags étaient arrivés.

Je ne sais pas s’il s’est passé un changement de comportement suite à la mise à jour de Gitea, mais quelque chose s’est quand même passé… On est un peu à espérer que le problème fut juste circonscrit à SPIP et sa branche 4.1…

Ces commits intermédiaires (des reports) apparaissent dans les notifications de shiraz
Le dernier perdu a priori, fut envoyé le 15 juin à 10h55 :

Ce commit (qui d’ailleurs ne corrige pas grand chose :man_facepalming:t2: hum) a tout l’historique qui manque ensuite au report suivant (comme si il y a eu un rebasage depuis un commit antérieur, avec un push --force, mais ça ne provient a priori pas de cédric).

Suivant qui semble être le 28 juin à 10h31 (je coupe le texte de log, c’est pas important)

Et si on regarde on voit que le premier 86a9705b suit le commit c79034a5ad du 1er juin donc, ce qui n’est a priori pas le parent attendu.

Bref… Croisons les doigts

  • que c’était plus ou moins tout le même souci
  • que tout est maintenant réglé
  • et que ça n’arrivera plus !

Bonjour

Pour information la cause du problème a été identifié.
C’est une erreur de configuration d’un IDE qui avait un mode pour envoyer les tags locaux en plus des commits prévus.

Cela a été corrigé et une demande d’évolution coté gitea a été ouverte pour gérer ce cas de figure.