From 61bf2cfd988b8de9e8cdfaa2773f79495a666e0b Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 17 Sep 2026 14:59:02 +0000 Subject: [PATCH] =?UTF-8?q?regla=202=20ter:=20el=20comando=20NO=20es=20el?= =?UTF-8?q?=20culpable=20=E2=80=94=20probado=20en=20un=20repo=20de=20jugue?= =?UTF-8?q?te?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Pasó dos veces el mismo día, con el mismo reflog: commit propio, `(start): checkout `, `(finish): returning to main`, y ni un `pick` en el medio. Antes de escribir otra hipótesis, se probó: dos clones de juguete, el otro empuja, yo commiteo local, `git pull --rebase -q origin main` ⇒ mi commit SE REAPLICA y mi fichero sigue. O sea que `pull --rebase` hace lo suyo, y lo que falla es que este árbol lo comparten varios agentes y alguien mueve `refs/heads/main` mientras el rebase está en vuelo. La receta práctica no cambia (mirar `git log -1` después de cada pull; recuperar con reflog + cherry-pick), pero el diagnóstico sí: evita ir a buscar el bug al lugar equivocado. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index 6b675cca..ad9432fa 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -134,7 +134,16 @@ f3d7be6c HEAD@{2}: commit: los 9 daemons propios entran al catálogo… ← **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 +⚠ **PASÓ DOS VECES EL MISMO DÍA** (2026-09-16 y 2026-09-17), con el mismo reflog: `commit` propio, +`(start): checkout `, `(finish): returning to refs/heads/main` — y ni un `pick` en el medio. + +**Y el comando NO es el culpable: se reprodujo en un repo de juguete y ahí funciona bien.** Dos +clones, el otro empuja, yo commiteo local, `git pull --rebase -q origin main` ⇒ **mi commit se +reaplica y mi fichero sigue ahí**. O sea que lo que falla no es `pull --rebase`: es que este árbol +lo comparten varios agentes y **alguien mueve `refs/heads/main` mientras el rebase está en vuelo**. +La receta práctica no cambia; el diagnóstico sí, y evita ir a buscar el bug al lugar equivocado. + +⚠ **La CAUSA exacta 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