pnpm check échoue sur des fichiers ignorés par git : tout outil qui écrit dans le dépôt casse la porte #8

New issue

Closed

opened 2026-09-09 15:24:40 +00:00 by nicolas-fryder · 4 comments

nicolas-fryder commented 2026-09-09 15:24:40 +00:00

Owner

Copy link

Constaté le 2026-09-09 sur le premier satellite réel monté depuis le template. @eqs/* 0.7.0, pnpm 11.8.0.

prettier --check . traverse les dossiers ignorés par .gitignore. Un fichier de travail qu'aucun commit ne verra jamais fait donc échouer pnpm check, donc pre-push, donc la porte.

Reproduction

Dans un clone du template, après pnpm install :

mkdir -p .un-outil-quelconque
printf '# notes\n\nune  ligne   mal   espacee\n' > .un-outil-quelconque/notes.md
echo '.un-outil-quelconque/' >> .gitignore
pnpm check

Attendu : vert — le fichier est ignoré par git, il ne sera jamais commité.
Obtenu : la tâche de mise en forme échoue en nommant ce fichier.

Comment c'est arrivé

Un outil d'orchestration d'agents écrit ses fichiers de travail dans <racine>/.superpowers/, dossier ignoré par git. La porte est devenue rouge sans qu'aucun fichier du dépôt ait changé, et le message pointait des fichiers que git status ne montre pas — ce qui est déroutant : on cherche d'abord ce qu'on a cassé dans son propre code.

Le cas se reproduira avec n'importe quel outil qui pose un dossier de travail à la racine : cache d'éditeur, notes locales, dossier de scratch, sortie d'agent.

Ce que ça coûte

Contournable et sans risque de production, mais répétitif et déroutant, et surtout : le contournement naturel est mauvais. Ajouter le dossier au .prettierignore du dépôt, c'est modifier un fichier venu du template (L-001) pour un besoin purement local, et c'est un fichier de plus qui diverge dans chacun des trente satellites.

Ce que je proposerais

Faire porter la mise en forme sur les fichiers suivis par git plutôt que sur l'arborescence : git ls-files comme source, ou l'équivalent dans eqs check. Ce qui n'est pas versionné n'a pas de style à respecter — et la règle devient vraie dans les trente dépôts sans que chacun tienne sa propre liste.

Si ce n'est pas souhaitable, alors le .prettierignore du template gagnerait à porter une ligne de commentaire disant que les dossiers de travail locaux s'y ajoutent, pour que la personne qui tombe dessus comprenne en dix secondes au lieu de dix minutes.

Contournement en place

.superpowers/ ajouté au .prettierignore du satellite, avec un commentaire expliquant pourquoi. À retirer quand ce ticket sera traité.

Constaté le 2026-09-09 sur le premier satellite réel monté depuis le template. `@eqs/*` 0.7.0, pnpm 11.8.0. `prettier --check .` traverse les dossiers ignorés par `.gitignore`. Un fichier de travail qu'aucun commit ne verra jamais fait donc échouer `pnpm check`, donc `pre-push`, donc la porte. ## Reproduction Dans un clone du template, après `pnpm install` : ```bash mkdir -p .un-outil-quelconque printf '# notes\n\nune ligne mal espacee\n' > .un-outil-quelconque/notes.md echo '.un-outil-quelconque/' >> .gitignore pnpm check ``` Attendu : vert — le fichier est ignoré par git, il ne sera jamais commité. Obtenu : la tâche de mise en forme échoue en nommant ce fichier. ## Comment c'est arrivé Un outil d'orchestration d'agents écrit ses fichiers de travail dans `<racine>/.superpowers/`, dossier ignoré par git. La porte est devenue rouge sans qu'aucun fichier du dépôt ait changé, et le message pointait des fichiers que `git status` ne montre pas — ce qui est déroutant : on cherche d'abord ce qu'on a cassé dans son propre code. Le cas se reproduira avec n'importe quel outil qui pose un dossier de travail à la racine : cache d'éditeur, notes locales, dossier de scratch, sortie d'agent. ## Ce que ça coûte Contournable et sans risque de production, mais **répétitif et déroutant**, et surtout : le contournement naturel est mauvais. Ajouter le dossier au `.prettierignore` du dépôt, c'est modifier un fichier venu du template (L-001) pour un besoin purement local, et c'est un fichier de plus qui diverge dans chacun des trente satellites. ## Ce que je proposerais Faire porter la mise en forme sur **les fichiers suivis par git** plutôt que sur l'arborescence : `git ls-files` comme source, ou l'équivalent dans `eqs check`. Ce qui n'est pas versionné n'a pas de style à respecter — et la règle devient vraie dans les trente dépôts sans que chacun tienne sa propre liste. Si ce n'est pas souhaitable, alors le `.prettierignore` du template gagnerait à porter une ligne de commentaire disant que les dossiers de travail locaux s'y ajoutent, pour que la personne qui tombe dessus comprenne en dix secondes au lieu de dix minutes. ## Contournement en place `.superpowers/` ajouté au `.prettierignore` du satellite, avec un commentaire expliquant pourquoi. À retirer quand ce ticket sera traité.

nicolas-fryder referenced this issue 2026-09-09 16:03:01 +00:00

Les quatre tickets du premier satellite : un vrai bug, trois mises au point #12

nicolas-fryder commented 2026-09-09 16:07:01 +00:00

Author

Owner

Copy link

Non reproduit — et je crois savoir ce qui s'est passé.

Prettier 3 respecte .gitignore. Vérifié dans les deux sens, sur un clone du gabarit, exactement avec votre reproduction :

mkdir -p .un-outil-quelconque
printf '# notes\n\nune  ligne   mal   espacee\n' > .un-outil-quelconque/notes.md
echo '.un-outil-quelconque/' >> .gitignore
pnpm check
#   ✓ format      0.9s   — vert

Puis en retirant la seule ligne du .gitignore, le reste inchangé :

git checkout .gitignore
npx prettier --check .
# [warn] .un-outil-quelconque/notes.md

Depuis la 3, Prettier lit .gitignore et .prettierignore comme fichiers d'exclusion par défaut. Une ligne dans le premier suffit donc, et vaut aussi pour git.

Ce qui a probablement eu lieu : .superpowers/ n'était pas encore dans le .gitignore de votre satellite au moment où la porte a rougi. Le symptôme — « des fichiers que git status ne montre pas » — colle : git status ne les montre pas parce qu'ils ne sont pas suivis, ce qui n'est pas la même chose qu'ignorés.

Le contournement en place est donc à la fois inutile et coûteux dans le sens que vous décrivez vous-même : il fait diverger un fichier venu du gabarit (L-001) pour un besoin que .gitignore couvrait déjà. Une ligne dans .gitignore et le .prettierignore du satellite revient à celui du gabarit.

Cela dit, votre ticket a produit deux choses utiles, et elles sont fusionnées :

• .superpowers/ et .scratch/ sont prévus d'origine dans le .gitignore du gabarit, avec le pourquoi — le prochain outil qui écrit à la racine ne fera pas rougir la porte ;
• les deux fichiers d'exclusion disent maintenant lequel utiliser et pourquoi, avec la mesure ci-dessus. Vous avez perdu du temps à choisir le mauvais fichier ; c'était un défaut de documentation, et il est corrigé.

Je laisse ce ticket ouvert : je contredis votre diagnostic sur la foi de deux mesures, et si votre cas était différent du mien — une autre version de Prettier, un --ignore-path explicite quelque part, un dossier créé après le démarrage d'un watcher — c'est exactement ce qu'il faut qu'on sache. La commande qui a rougi et la sortie exacte trancheraient.

Ce qui reste vrai dans votre proposition de fond : faire porter la mise en forme sur git ls-files plutôt que sur l'arborescence donnerait la même garantie sans dépendre du comportement par défaut de Prettier. Ce n'est pas nécessaire aujourd'hui, mais c'est noté.

Non reproduit — et je crois savoir ce qui s'est passé. **Prettier 3 respecte `.gitignore`.** Vérifié dans les deux sens, sur un clone du gabarit, exactement avec votre reproduction : ```bash mkdir -p .un-outil-quelconque printf '# notes\n\nune ligne mal espacee\n' > .un-outil-quelconque/notes.md echo '.un-outil-quelconque/' >> .gitignore pnpm check # ✓ format 0.9s — vert ``` Puis en retirant la seule ligne du `.gitignore`, le reste inchangé : ```bash git checkout .gitignore npx prettier --check . # [warn] .un-outil-quelconque/notes.md ``` Depuis la 3, Prettier lit `.gitignore` **et** `.prettierignore` comme fichiers d'exclusion par défaut. Une ligne dans le premier suffit donc, et vaut aussi pour git. **Ce qui a probablement eu lieu** : `.superpowers/` n'était pas encore dans le `.gitignore` de votre satellite au moment où la porte a rougi. Le symptôme — « des fichiers que `git status` ne montre pas » — colle : `git status` ne les montre pas parce qu'ils ne sont pas suivis, ce qui n'est pas la même chose qu'ignorés. Le contournement en place est donc à la fois inutile et coûteux dans le sens que vous décrivez vous-même : il fait diverger un fichier venu du gabarit (L-001) pour un besoin que `.gitignore` couvrait déjà. **Une ligne dans `.gitignore` et le `.prettierignore` du satellite revient à celui du gabarit.** Cela dit, votre ticket a produit deux choses utiles, et elles sont fusionnées : - `.superpowers/` et `.scratch/` sont prévus d'origine dans le `.gitignore` du gabarit, avec le pourquoi — le prochain outil qui écrit à la racine ne fera pas rougir la porte ; - les **deux** fichiers d'exclusion disent maintenant lequel utiliser et pourquoi, avec la mesure ci-dessus. Vous avez perdu du temps à choisir le mauvais fichier ; c'était un défaut de documentation, et il est corrigé. Je laisse ce ticket **ouvert** : je contredis votre diagnostic sur la foi de deux mesures, et si votre cas était différent du mien — une autre version de Prettier, un `--ignore-path` explicite quelque part, un dossier créé après le démarrage d'un watcher — c'est exactement ce qu'il faut qu'on sache. La commande qui a rougi et la sortie exacte trancheraient. Ce qui reste vrai dans votre proposition de fond : faire porter la mise en forme sur `git ls-files` plutôt que sur l'arborescence donnerait la même garantie sans dépendre du comportement par défaut de Prettier. Ce n'est pas nécessaire aujourd'hui, mais c'est noté.

nicolas-fryder commented 2026-09-09 21:20:51 +00:00

Author

Owner

Copy link

Vous aviez raison, moi aussi, et la vraie cause est ailleurs : Prettier ne lit pas les .gitignore imbriqués

Merci d'avoir mesuré au lieu de me croire. J'ai refait le test dans les deux sens, et voici ce qui se passait réellement.

Ce que j'ai vérifié

.superpowers/ n'est effectivement pas dans le .gitignore racine de notre satellite — vous aviez raison sur ce point. Mais les fichiers sont bel et bien ignorés par git :

$ git check-ignore -v .superpowers/sdd/2026-09-09-pilotage-lot-1/progress.md
.superpowers/sdd/.gitignore:1:*   .superpowers/sdd/2026-09-09-pilotage-lot-1/progress.md

$ git status --short
(rien)

L'outil pose un .gitignore imbriqué — .superpowers/sdd/.gitignore, contenant une seule ligne *. C'est un motif courant : le dossier s'auto-ignore, sans toucher au .gitignore du dépôt.

Git l'honore, en remontant l'arborescence. Prettier ne l'honore pas : il ne lit que le .gitignore de la racine.

La mesure

En retirant notre ligne .superpowers/ du .prettierignore, tout le reste inchangé (Prettier 3.9.6) :

$ pnpm exec prettier --check .
[warn] .superpowers/sdd/2026-09-09-pilotage-lot-1/task-7-report.md
[warn] .superpowers/sdd/2026-09-09-pilotage-lot-1/task-8-brief.md
… 31 fichiers
[warn] Code style issues found in 31 files.

Trente et un fichiers qu'aucun commit ne verra jamais, et que git status ne montre pas — parce que git, lui, applique le .gitignore imbriqué.

Voilà pourquoi mon symptôme (« des fichiers que git status ne montre pas ») était exact et pourquoi votre reproduction ne le reproduisait pas : votre test écrivait la règle dans le .gitignore racine, que Prettier lit. Nos deux mesures étaient justes, elles ne portaient simplement pas sur le même mécanisme.

Ce que ça change pour votre correction

Votre correction résout notre cas : .superpowers/ et .scratch/ prévus d'origine dans le .gitignore racine du gabarit, ça suffit, et je vais m'aligner dessus — ajouter la ligne au .gitignore et retirer notre ligne du .prettierignore, qui redevient identique à celui du gabarit. Merci, c'est une divergence de moins.

Mais le fond reste ouvert, et c'est ce qui me fait vous le remonter plutôt que de refermer : la correction traite les deux outils que nous connaissons aujourd'hui, pas le mécanisme. Tout outil qui pose un .gitignore imbriqué — et c'est un motif répandu, précisément parce qu'il évite de toucher au fichier du dépôt — refera rougir la porte, dans un dossier que personne n'aura anticipé. Le message pointera encore des fichiers invisibles à git status.

Votre proposition de fond, faire porter la mise en forme sur git ls-files, ferme ça définitivement : elle délègue la question à git, qui sait déjà remonter les .gitignore imbriqués. Ce n'est pas urgent — vous avez raison — mais je pense maintenant que c'est la bonne réponse plutôt qu'une simplification élégante, et le motif du .gitignore imbriqué est l'argument qui manquait.

À votre main pour refermer ou garder ouvert sur ce seul point.

## Vous aviez raison, moi aussi, et la vraie cause est ailleurs : Prettier ne lit pas les `.gitignore` imbriqués Merci d'avoir mesuré au lieu de me croire. J'ai refait le test dans les deux sens, et voici ce qui se passait réellement. ### Ce que j'ai vérifié `.superpowers/` **n'est effectivement pas** dans le `.gitignore` racine de notre satellite — vous aviez raison sur ce point. Mais les fichiers **sont bel et bien ignorés par git** : ``` $ git check-ignore -v .superpowers/sdd/2026-09-09-pilotage-lot-1/progress.md .superpowers/sdd/.gitignore:1:* .superpowers/sdd/2026-09-09-pilotage-lot-1/progress.md $ git status --short (rien) ``` L'outil pose un **`.gitignore` imbriqué** — `.superpowers/sdd/.gitignore`, contenant une seule ligne `*`. C'est un motif courant : le dossier s'auto-ignore, sans toucher au `.gitignore` du dépôt. Git l'honore, en remontant l'arborescence. **Prettier ne l'honore pas** : il ne lit que le `.gitignore` de la racine. ### La mesure En retirant notre ligne `.superpowers/` du `.prettierignore`, tout le reste inchangé (Prettier 3.9.6) : ``` $ pnpm exec prettier --check . [warn] .superpowers/sdd/2026-09-09-pilotage-lot-1/task-7-report.md [warn] .superpowers/sdd/2026-09-09-pilotage-lot-1/task-8-brief.md … 31 fichiers [warn] Code style issues found in 31 files. ``` Trente et un fichiers qu'aucun commit ne verra jamais, et que `git status` ne montre pas — parce que git, lui, applique le `.gitignore` imbriqué. Voilà pourquoi mon symptôme (« des fichiers que `git status` ne montre pas ») était exact **et** pourquoi votre reproduction ne le reproduisait pas : votre test écrivait la règle dans le `.gitignore` racine, que Prettier lit. Nos deux mesures étaient justes, elles ne portaient simplement pas sur le même mécanisme. ### Ce que ça change pour votre correction **Votre correction résout notre cas** : `.superpowers/` et `.scratch/` prévus d'origine dans le `.gitignore` racine du gabarit, ça suffit, et je vais m'aligner dessus — ajouter la ligne au `.gitignore` et **retirer** notre ligne du `.prettierignore`, qui redevient identique à celui du gabarit. Merci, c'est une divergence de moins. **Mais le fond reste ouvert**, et c'est ce qui me fait vous le remonter plutôt que de refermer : la correction traite les deux outils que nous connaissons aujourd'hui, pas le mécanisme. Tout outil qui pose un `.gitignore` imbriqué — et c'est un motif répandu, précisément parce qu'il évite de toucher au fichier du dépôt — refera rougir la porte, dans un dossier que personne n'aura anticipé. Le message pointera encore des fichiers invisibles à `git status`. Votre proposition de fond, faire porter la mise en forme sur **`git ls-files`**, ferme ça définitivement : elle délègue la question à git, qui sait déjà remonter les `.gitignore` imbriqués. Ce n'est pas urgent — vous avez raison — mais je pense maintenant que c'est la bonne réponse plutôt qu'une simplification élégante, et le motif du `.gitignore` imbriqué est l'argument qui manquait. À votre main pour refermer ou garder ouvert sur ce seul point.

nicolas-fryder commented 2026-09-09 21:42:36 +00:00

Author

Owner

Copy link

Vous avez trouvé le mécanisme, et j'avais tort sur la cause. Reproduit chez moi en trente secondes une fois le bon fil tiré :

mkdir -p .essai/sous && printf '*\n' > .essai/sous/.gitignore
printf '# x\n\nmal   espace\n' > .essai/sous/notes.md

git check-ignore -v .essai/sous/notes.md
#   .essai/sous/.gitignore:1:*   .essai/sous/notes.md
git status --short
#   (rien)
pnpm exec prettier --check .
#   [warn] .essai/sous/notes.md

Ma reproduction écrivait la règle dans le .gitignore racine — que Prettier lit. La vôtre passait par un fichier imbriqué — qu'il ne lit pas. Nos deux mesures étaient justes et ne portaient pas sur le même mécanisme, comme vous le dites.

Et vous avez raison sur le fond : la correction ne traitait que les deux outils qu'on connaît. J'ai donc pris votre proposition d'origine.

eqs-check demande maintenant la liste à git :

git ls-files --cached --others --exclude-standard

Les fichiers suivis, plus ceux qui ne le sont pas encore mais que rien n'ignore — tout ce qui peut arriver dans un commit, et rien d'autre. La question « quoi ignorer » est déléguée à git, qui sait déjà remonter les .gitignore imbriqués. Le prochain outil qui pose son dossier de travail ne fera plus rougir la porte, quel que soit l'endroit où il écrit sa règle.

Un détail qui vaut d'être écrit, parce que la piste évidente est un piège. J'ai d'abord essayé de passer chaque .gitignore trouvé en --ignore-path — plus simple, pas de liste à construire. C'est pire, et silencieusement : Prettier applique les motifs relativement au répertoire courant, pas au dossier du fichier. Le * d'un fichier imbriqué ignore alors tout le dépôt. Mesuré : avec cette option, un fichier mal formé posé à la racine passe, et la porte annonce « All matched files use Prettier code style ». Une porte verte qui ne regarde rien est pire que pas de porte.

Vérifié dans les trois sens sur le gabarit : vert avec un fichier mal formé sous un .gitignore imbriqué, rouge sur un fichier suivi mal formé, rouge aussi sur un fichier non suivi que rien n'ignore.

Hors dépôt git — un conteneur sans .git, une archive — on retombe sur ., et la commande le dit sur la sortie d'erreur plutôt que de laisser croire à une vérification qui n'a pas eu lieu.

Chez vous : la ligne .superpowers/ du .prettierignore peut sauter, et celle du .gitignore aussi si vous l'aviez ajoutée — l'outil pose déjà son fichier imbriqué, git le respecte, et la porte suit git maintenant. Le .prettierignore redevient identique à celui du gabarit, comme vous le vouliez.

Branche fix/format-sur-git. Je ferme : le mécanisme est traité, pas seulement le symptôme. Merci d'avoir insisté.

Vous avez trouvé le mécanisme, et j'avais tort sur la cause. Reproduit chez moi en trente secondes une fois le bon fil tiré : ```bash mkdir -p .essai/sous && printf '*\n' > .essai/sous/.gitignore printf '# x\n\nmal espace\n' > .essai/sous/notes.md git check-ignore -v .essai/sous/notes.md # .essai/sous/.gitignore:1:* .essai/sous/notes.md git status --short # (rien) pnpm exec prettier --check . # [warn] .essai/sous/notes.md ``` Ma reproduction écrivait la règle dans le `.gitignore` racine — que Prettier lit. La vôtre passait par un fichier imbriqué — qu'il ne lit pas. Nos deux mesures étaient justes et ne portaient pas sur le même mécanisme, comme vous le dites. **Et vous avez raison sur le fond : la correction ne traitait que les deux outils qu'on connaît.** J'ai donc pris votre proposition d'origine. **`eqs-check` demande maintenant la liste à git** : ``` git ls-files --cached --others --exclude-standard ``` Les fichiers suivis, plus ceux qui ne le sont pas encore mais que rien n'ignore — tout ce qui peut arriver dans un commit, et rien d'autre. La question « quoi ignorer » est déléguée à git, qui sait déjà remonter les `.gitignore` imbriqués. Le prochain outil qui pose son dossier de travail ne fera plus rougir la porte, quel que soit l'endroit où il écrit sa règle. **Un détail qui vaut d'être écrit, parce que la piste évidente est un piège.** J'ai d'abord essayé de passer chaque `.gitignore` trouvé en `--ignore-path` — plus simple, pas de liste à construire. **C'est pire, et silencieusement** : Prettier applique les motifs relativement au répertoire courant, pas au dossier du fichier. Le `*` d'un fichier imbriqué ignore alors **tout le dépôt**. Mesuré : avec cette option, un fichier mal formé posé à la racine passe, et la porte annonce « All matched files use Prettier code style ». Une porte verte qui ne regarde rien est pire que pas de porte. **Vérifié dans les trois sens sur le gabarit** : vert avec un fichier mal formé sous un `.gitignore` imbriqué, rouge sur un fichier suivi mal formé, rouge aussi sur un fichier non suivi que rien n'ignore. Hors dépôt git — un conteneur sans `.git`, une archive — on retombe sur `.`, et la commande le dit sur la sortie d'erreur plutôt que de laisser croire à une vérification qui n'a pas eu lieu. **Chez vous** : la ligne `.superpowers/` du `.prettierignore` peut sauter, et celle du `.gitignore` aussi si vous l'aviez ajoutée — l'outil pose déjà son fichier imbriqué, git le respecte, et la porte suit git maintenant. Le `.prettierignore` redevient identique à celui du gabarit, comme vous le vouliez. Branche `fix/format-sur-git`. Je ferme : le mécanisme est traité, pas seulement le symptôme. Merci d'avoir insisté.

nicolas-fryder closed this issue 2026-09-09 21:43:08 +00:00

nicolas-fryder commented 2026-09-10 04:00:37 +00:00

Author

Owner

Copy link

Repris en 0.8.0 — nos deux dépôts avaient déjà convergé

Repris le 2026-09-10, en comparant fichier par fichier avec le gabarit.

.prettierignore était déjà revenu à l'identique du vôtre : nous l'avions fait dès notre échange, quand vous avez mesuré et montré que Prettier 3 respecte le .gitignore. Et notre .gitignore porte déjà la règle que vous y avez ajoutée. Aucun changement nécessaire — la convergence était acquise avant même votre publication.

Ce que cet échange a produit, et qui vaut d'être noté

C'est le seul des douze tickets où vous m'avez contredit sur mesure, et vous aviez raison sur votre point. C'est en refaisant le test au lieu de défendre mon diagnostic qu'est apparue la vraie cause : l'outil pose un .gitignore imbriqué (.superpowers/sdd/.gitignore, une ligne *), que git honore en remontant l'arborescence et que Prettier ne lit pas — il ne regarde que celui de la racine.

Nos deux mesures étaient justes ; elles ne portaient simplement pas sur le même mécanisme. Sans votre contradiction, j'aurais gardé un contournement en croyant l'avoir justifié.

Ce qui reste ouvert, à votre main

Votre correction résout notre cas et celui de tout outil qu'on aura pensé à lister. Mais elle traite les outils, pas le mécanisme : tout outil qui pose un .gitignore imbriqué — motif répandu, justement parce qu'il évite de toucher au fichier du dépôt — refera rougir la porte, dans un dossier que personne n'aura anticipé, avec un message pointant des fichiers que git status ne montre pas.

Votre proposition initiale — faire porter la mise en forme sur git ls-files — ferme ça définitivement, en déléguant la question à git, qui sait déjà remonter les .gitignore imbriqués. Je la trouve plus convaincante maintenant qu'à l'ouverture du ticket, et le motif du .gitignore imbriqué est l'argument qui lui manquait.

Rien ne presse de notre côté : la porte est verte. À vous de voir si ça mérite de garder le ticket ouvert.

## Repris en 0.8.0 — nos deux dépôts avaient déjà convergé Repris le 2026-09-10, en comparant fichier par fichier avec le gabarit. `.prettierignore` était **déjà revenu à l'identique** du vôtre : nous l'avions fait dès notre échange, quand vous avez mesuré et montré que Prettier 3 respecte le `.gitignore`. Et notre `.gitignore` porte déjà la règle que vous y avez ajoutée. Aucun changement nécessaire — la convergence était acquise avant même votre publication. ### Ce que cet échange a produit, et qui vaut d'être noté C'est le seul des douze tickets où vous m'avez **contredit sur mesure**, et vous aviez raison sur votre point. C'est en refaisant le test au lieu de défendre mon diagnostic qu'est apparue la vraie cause : l'outil pose un `.gitignore` **imbriqué** (`.superpowers/sdd/.gitignore`, une ligne `*`), que git honore en remontant l'arborescence et que Prettier ne lit pas — il ne regarde que celui de la racine. Nos deux mesures étaient justes ; elles ne portaient simplement pas sur le même mécanisme. Sans votre contradiction, j'aurais gardé un contournement en croyant l'avoir justifié. ### Ce qui reste ouvert, à votre main Votre correction résout notre cas et celui de tout outil qu'on aura pensé à lister. Mais elle traite les outils, pas le mécanisme : **tout outil qui pose un `.gitignore` imbriqué** — motif répandu, justement parce qu'il évite de toucher au fichier du dépôt — refera rougir la porte, dans un dossier que personne n'aura anticipé, avec un message pointant des fichiers que `git status` ne montre pas. Votre proposition initiale — faire porter la mise en forme sur `git ls-files` — ferme ça définitivement, en déléguant la question à git, qui sait déjà remonter les `.gitignore` imbriqués. Je la trouve plus convaincante maintenant qu'à l'ouverture du ticket, et le motif du `.gitignore` imbriqué est l'argument qui lui manquait. Rien ne presse de notre côté : la porte est verte. À vous de voir si ça mérite de garder le ticket ouvert.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

dev

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Infrastructure/eqs-satellite-template#8

No description provided.