From 7be069cc5ab5362890b4a2e7b26bdd937cd28c81 Mon Sep 17 00:00:00 2001 From: Sergio Date: Wed, 16 Sep 2026 20:04:03 +0000 Subject: [PATCH] =?UTF-8?q?regla=202=20ter:=20separar=20lo=20medido=20de?= =?UTF-8?q?=20lo=20supuesto=20=E2=80=94=20la=20causa=20del=20commit=20perd?= =?UTF-8?q?ido=20NO=20est=C3=A1=20determinada?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El texto de esta mañana afirmaba que «otro agente movió la rama», y daba como prueba que los commits que trajo el `pull` cuelgan del commit ANTERIOR al mío. Eso no es prueba de nada: es lo normal cuando el otro lado empujó desde una máquina que había hecho `fetch` antes — en este caso la laptop, cuyos tres commits llevan su huso (-04:00) y no pasaron por acá. Lo MEDIDO es el reflog (entre `start` y `finish` no hay un solo `pick`) y que los diez ficheros desaparecieron también del ÁRBOL, cosa que un `reset --hard`/`checkout` concurrente sí explicaría. Queda escrito como hipótesis, que es lo que es. La receta práctica no cambia y es lo que vale: mirar `git log --oneline -1` después de cada `pull --rebase`, y si el commit propio no está, `git reflog` + `cherry-pick`. De paso, descartado el sospechoso obvio: `cosecha-cron.sh` NO hace pull ni reset — commitea acotado por pathspec y si el push falla sólo lo anota. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 132f4ee0..6b675cca 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -131,11 +131,16 @@ El reflog lo explica y es lo único que lo explica: f3d7be6c HEAD@{2}: commit: los 9 daemons propios entran al catálogo… ← el mío ``` -**Entre `start` y `finish` no hay ni un `pick`**: el rebase no encontró NADA que reaplicar. Eso pasa -cuando, en el momento del `pull`, el commit propio ya no colgaba de `main` — otro agente movió la -rama (los tres commits que trajo el `pull` tienen de padre al commit ANTERIOR al mío, así que main -había retrocedido). El `--rebase` no rompió nada: rebasó una rama de la que tu commit ya había sido -sacado, y como `-q` calla, el resultado se ve igual que un pull limpio. +**Entre `start` y `finish` no hay ni un `pick`**: el rebase no encontró NADA que reaplicar, y con +`-q` eso se ve igual que un pull limpio. + +⚠ **La CAUSA no está determinada, y conviene decirlo así en vez de inventarla.** Lo medido es el +reflog de arriba y que los diez ficheros desaparecieron también del ÁRBOL, que es lo que un +`reset --hard` o un `checkout` concurrente de otro agente sí explicaría. Lo que NO es evidencia —y +se escribió como si lo fuera— es que los commits que trajo el `pull` cuelguen del commit anterior al +mío: eso es lo normal cuando el otro lado empujó desde una máquina que había hecho `fetch` antes, y +no dice nada de lo que pasó acá. **Que el árbol perdiera los ficheros es el dato fuerte; el resto, +hipótesis.** **Qué hacer:**