regla 2 ter: separar lo medido de lo supuesto — la causa del commit perdido NO está determinada

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) <noreply@anthropic.com>
This commit is contained in:
Sergio
2026-09-16 20:04:03 +00:00
co-authored by Claude Opus 5
parent 96d27a8ed7
commit 7be069cc5a
+10 -5
View File
@@ -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:**