From 602233b8a5b66b9d3798c7db81c8a33314e443df Mon Sep 17 00:00:00 2001 From: Sergio Date: Sun, 6 Sep 2026 02:00:05 +0000 Subject: [PATCH] =?UTF-8?q?CLAUDE.md=20regla=202:=20acotar=20el=20COMMIT?= =?UTF-8?q?=20por=20pathspec,=20no=20s=C3=B3lo=20el=20add?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Medido hoy, y contra mi propia metida de pata: el commit ff0b556 se llevó dentro un rename y un borrado de otro agente HABIENDO usado `git add ` y `git commit` sin -a. O sea, cumpliendo la regla al pie de la letra. La causa es que el índice es estado COMPARTIDO entre los agentes que trabajan el árbol: `git commit` commitea el índice entero, no lo que uno acaba de añadir. Comprobado en un repo de juguete en los dos sentidos: git add mio.txt && git commit -m … -> arrastra el ajeno.txt que el otro tenía staged git commit -m … -- mio.txt -> sólo mio.txt; lo del otro queda staged e intacto La regla decía «sólo rutas explícitas» y esa frase apunta al `add`, que no es donde está el peligro. Queda apuntando al `commit`, que es donde sí. Lo levantó la sesión hammer-f8 al ver sus ficheros dentro de mi commit. --- CLAUDE.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index e08f4937..b61eb80e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -29,12 +29,29 @@ correcta. Por eso el worker corre con `JOBS=1`. que usarlo nos serializa con la granja además de entre nosotros. **No está dentro de `hammer build` a propósito**: esos scripts lo toman por fuera y hammer se bloquearía contra ellos. -## 2. Nunca `git add -A` +## 2. Nunca `git add -A` — y acotar el COMMIT, no sólo el `add` Sólo rutas explícitas. Un `add -A` arrastra al commit los ficheros a medias de otro agente. Commits granulares, en español, directo sobre `main`, y `git push` tras cada unidad de trabajo (el `origin` empuja a gitea **y** al espejo privado de GitHub; ver `scripts/espejo-setup.sh`). +⚠ **«Rutas explícitas» en el `add` NO ALCANZA, y esto es medido, no teórico** (2026-09-06): el +commit `ff0b556` se llevó dentro un rename y un borrado de otro agente **habiendo usado +`git add recipes/firefox.toml` y `git commit` sin `-a`**. La causa es que **el índice es estado +COMPARTIDO**: `git commit` commitea el índice ENTERO, no lo que vos acabás de añadir, así que +cualquier cosa que el otro agente dejó en `git add` viaja en tu commit. Comprobado en un repo de +juguete, en los dos sentidos: + +```sh +git add mio.txt && git commit -m … # ⇒ arrastra ajeno.txt (estaba staged por el otro) +git commit -m … -- mio.txt # ⇒ SÓLO mio.txt; lo del otro queda staged e intacto +``` + +**Entonces: `git commit -m "…" -- `.** El `--` acota el commit por pathspec y es lo único que +aísla de verdad. Vale también para `git commit -F -`. Corolario: no dar por bueno el alcance sin +mirarlo — `git show --stat` sobre el commit recién hecho cuesta un segundo y es la única forma de +enterarse el mismo día en vez de por el otro agente. + ## 3. Antes de dar un artefacto por presente, mirá que tenga contenido Un directorio **vacío** en el store no es un artefacto: es un nombre. `Store::has` ya lo rechaza y