Purge executee le 2026-09-02 : 9 752 -> 1 034 branches distantes (8 718 supprimees). Cette issue porte le residu a trier a la main : les 125 branches qui n'ont jamais eu de PR et dont le contenu n'est pas dans main.
Ce qui a ete supprime, et pourquoi c'etait sans risque
| bucket |
n |
critere |
| PR mergee (squash) |
8 581 |
le nom de branche est la tete d'une PR merged_at != null |
contenu deja dans main |
141 |
le SHA de tete est dans git rev-list origin/main |
Trois controles positifs avant execution, tous a 0 : intersection avec les 137 PRs ouvertes, occurrence de main, intersection avec les 125 ci-dessous.
Filet de securite : un manifeste nom<TAB>SHA de la totalite des 9 752 branches a ete pris avant la purge. Toute branche est restaurable :
git push origin <sha>:refs/heads/<nom>
Pourquoi cette purge n'etait pas de l'hygiene
Elle repare une mesure de cout CI. Un garde identique, meme commit :
|
checkout |
travail reel |
total |
ubuntu-latest |
40-51 s |
1-2 s |
45-57 s |
| auto-heberge |
80-148 s |
1-4 s |
88-162 s |
Le surcout etait au fetch, pas au calcul : chaque actions/checkout avec fetch-depth: 0 tirait les ~9 700 refs. La jambe auto-hebergee etait 2-3x plus lente par la seule faute du bric-a-brac de branches.
Le residu : 125 branches sans PR, hors main
Toutes portent 1 a 8 commits reels. Les plus substantielles :
| branche |
date |
contenu |
feat/lean-median-voter-strict-args |
2026-05-11 |
prove banks_set_condorcet in Voting.lean (sorry 2->1) — une preuve Lean qui elimine un sorry |
recovery/stash-po204-m15-refit-tuning |
2026-05-21 |
stash de recuperation, 75 fichiers |
fix/sudoku-search-reexec-v2 |
2026-05-31 |
re-execution Sudoku, 21 fichiers |
fix/sudoku-models-rebase-v2 |
2026-05-31 |
re-execution Sudoku, 16 fichiers |
feature/1273-prosody-tags-only |
2026-05-26 |
README audio, 9 fichiers |
fix/12798-c3-repair |
2026-08-24 |
REPAIR C.2/C.3, re-exec notebook GameTheory |
resolve/c1257-pr9128-search-yaml |
2026-08-04 |
resolution de conflit, 6 fichiers |
A GARDER explicitement : feature/runner-positive-control est dans ce bucket, et le corps de #13378 dit qu'elle ne doit jamais etre mergee — l'echec y est le livrable. Ne pas la supprimer par automatisme.
Sans valeur, verifie par sujet de commit : une part notable du residu est du bruit de relance CI (bump vide re-trigger PR gate, empty commit to refresh stale rollup, backup/*, fix/*-update-branch). Ces branches sont supprimables apres lecture, mais l'automatisme ne peut pas les distinguer d'une pepite : c'est pourquoi elles sont ici et non dans la purge.
Acceptance
La liste complete des 125 avec date, commits en avance et fichiers touches est reproductible :
git for-each-ref --format='%(refname:short)|%(committerdate:short)|%(objectname)' refs/remotes/origin
gh api "repos/jsboige/CoursIA/pulls?state=all&per_page=100" --paginate --jq '.[]|[.number,.state,(.merged_at//"null"),.head.ref]|@tsv'
See #14238
Purge executee le 2026-09-02 : 9 752 -> 1 034 branches distantes (8 718 supprimees). Cette issue porte le residu a trier a la main : les 125 branches qui n'ont jamais eu de PR et dont le contenu n'est pas dans
main.Ce qui a ete supprime, et pourquoi c'etait sans risque
merged_at != nullmaingit rev-list origin/mainTrois controles positifs avant execution, tous a 0 : intersection avec les 137 PRs ouvertes, occurrence de
main, intersection avec les 125 ci-dessous.Filet de securite : un manifeste
nom<TAB>SHAde la totalite des 9 752 branches a ete pris avant la purge. Toute branche est restaurable :Pourquoi cette purge n'etait pas de l'hygiene
Elle repare une mesure de cout CI. Un garde identique, meme commit :
ubuntu-latestLe surcout etait au
fetch, pas au calcul : chaqueactions/checkoutavecfetch-depth: 0tirait les ~9 700 refs. La jambe auto-hebergee etait 2-3x plus lente par la seule faute du bric-a-brac de branches.Le residu : 125 branches sans PR, hors
mainToutes portent 1 a 8 commits reels. Les plus substantielles :
feat/lean-median-voter-strict-argsprove banks_set_condorcet in Voting.lean (sorry 2->1)— une preuve Lean qui elimine unsorryrecovery/stash-po204-m15-refit-tuningfix/sudoku-search-reexec-v2fix/sudoku-models-rebase-v2feature/1273-prosody-tags-onlyfix/12798-c3-repairresolve/c1257-pr9128-search-yamlA GARDER explicitement :
feature/runner-positive-controlest dans ce bucket, et le corps de #13378 dit qu'elle ne doit jamais etre mergee — l'echec y est le livrable. Ne pas la supprimer par automatisme.Sans valeur, verifie par sujet de commit : une part notable du residu est du bruit de relance CI (
bump vide re-trigger PR gate,empty commit to refresh stale rollup,backup/*,fix/*-update-branch). Ces branches sont supprimables apres lecture, mais l'automatisme ne peut pas les distinguer d'une pepite : c'est pourquoi elles sont ici et non dans la purge.Acceptance
feat/lean-median-voter-strict-args: la preuvebanks_set_condorcetest-elle toujours absente demain? Si oui, la porter (anti-regression : unsorryelimine ne se perd pas).recovery/stash-po204-m15-refit-tuning(75 fichiers) : identifier ce que le stash contient et s'il a ete recree ailleurs.fix/sudoku-*-v2: verifier si la re-execution est encore due.feature/runner-positive-controlcomme conservee deliberement.La liste complete des 125 avec date, commits en avance et fichiers touches est reproductible :
See #14238