El guión avisaba en cada corrida de que el commit se había perdido, iba a recuperarlo, y el
cherry-pick le contestaba que el contenido ya estaba. Un guardián que grita siempre se ignora, así
que valía la pena encontrar por qué.
No era git: era la comprobación. El guión corre con `set -o pipefail` y comprobaba con
`git log … | grep -qF "$MSG"`. **`grep -q` sale en cuanto encuentra**, eso le manda SIGPIPE a
`git log`, que termina ≠0, y con `pipefail` la tubería entera se lee como FALLO **aunque el grep haya
encontrado**. Demostrado en una línea:
$ bash -c 'set -o pipefail; seq 1 100000 | grep -q "^5$" && echo OK || echo FALLO'
FALLO
Arreglado capturando la salida antes de comparar: sin tubería, sin SIGPIPE, sin falso positivo.
⇒ Y de paso desmiente lo que el propio guión daba por hecho: de las cinco «pérdidas» de commit que
motivaron escribirlo, al menos las últimas dos fueron ESTE falso positivo, no el rebase. Las
primeras sí están en el reflog con su `(start)`/`(finish)` sin `pick`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estrenando el guión con su propio commit saltó el caso: la comprobación por mensaje dio negativo,
el cherry-pick de recuperación salió con «the previous cherry-pick is now empty» y el guión abortó
con error… teniendo el contenido ya en el árbol.
Ahora distingue los dos casos: vacío ⇒ falso positivo de la comprobación, se aborta el cherry-pick y
se sigue; cualquier otro error ⇒ se aborta, se imprime el reflog y se sale ≠0 para que lo mire un
humano. Lo que importa es que el CONTENIDO esté, no que el sha coincida.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
En dos días, `git pull --rebase` se llevó por delante CINCO commits propios en este árbol
compartido, siempre con el mismo reflog: `commit:` mío, `(start): checkout <otro>`, `(finish):
returning to main`, y ni un `pick` en el medio. El comando no es el culpable —en un repo de juguete
reaplica bien— sino que alguien mueve `refs/heads/main` mientras el rebase está en vuelo.
La receta manual (CLAUDE.md regla 2 ter) funciona: mirar el log y recuperar con reflog +
cherry-pick. Esto es esa receta automatizada, porque **una regla que hay que acordarse de aplicar en
cada push es una regla que un día no se aplica**.
Hace, en orden: anota su HEAD · rebasa · COMPRUEBA que el commit sigue en la rama —por su mensaje,
no por el sha, que el rebase reescribe— · si no está lo recupera del reflog · empuja · verifica que
gitea quedó donde tiene que quedar · y si el espejo de GitHub quedó divergente lo realinea con
`--force-with-lease` (nunca `--force` a secas) y sólo tras comprobar que su contenido ya está en
nuestra historia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
