From 597406ad70edf35becbe1ab62c813b6ea91b9003 Mon Sep 17 00:00:00 2001
From: Sergio <sergio@gioser.net>
Date: Thu, 17 Sep 2026 16:55:42 +0000
Subject: [PATCH] =?UTF-8?q?git-sincronizar:=20gritaba=20=C2=ABel=20commit?=
 =?UTF-8?q?=20desapareci=C3=B3=C2=BB=20SIEMPRE=20=E2=80=94=20era=20`pipefa?=
 =?UTF-8?q?il`=20+=20SIGPIPE,=20no=20el=20rebase?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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>
---
 scripts/git-sincronizar.sh | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

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"