tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1572Shell 203Rust 109Markdown 993728 Definitions

git-sincronizar: gritaba «el commit desapareció» SIEMPRE — era `pipefail` + SIGPIPE, no el rebase

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>

597406ad70edf35becbe1ab62c813b6ea91b9003 · by Sergio · (1 month ago) · parent b98557078 · browse the tree at this commit

Semantic delta

No definition changed: this change is text, documentation or data.

1 files · +8 −1

diff --git a/scripts/git-sincronizar.sh b/scripts/git-sincronizar.sh
index 125861d0..3ee67d97 100755
--- a/scripts/git-sincronizar.sh
+++ b/scripts/git-sincronizar.sh
@@ -37,7 +37,14 @@ else
   git pull --rebase -q origin main || { echo "!!  el rebase falló — resolvé a mano"; exit 1; }
   # `git cherry` compara por PARCHE: el rebase le cambia el sha al commit, así que buscarlo por sha
   # daría un falso negativo y esto entraría en un bucle de cherry-picks duplicados.
-  if git log --oneline -20 | grep -qF "$MSG"; then
+  # ⚠ NADA DE `git log … | grep -q` ACÁ, y la causa es sutil: este script corre con `set -o
+  # pipefail`, y `grep -q` SALE EN CUANTO ENCUENTRA — lo que 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**. Resultado: el guión anunciaba «EL COMMIT DESAPARECIÓ» en cada corrida, se iba a
+  # recuperarlo, y el `cherry-pick` le decía que ya estaba. Un guardián que grita siempre se ignora.
+  # La salida se captura primero y se compara después: sin tubería, sin SIGPIPE, sin falso positivo.
+  RECIENTES=$(git log --format=%s -20)
+  if printf '%s\n' "$RECIENTES" | grep -qF "$MSG"; then
     echo "    ✓ el commit sobrevivió al rebase"
   else
     echo "!!  el commit no aparece en los últimos 20 tras el rebase — intento recuperarlo"