gioser

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 1184Shell 70Rust 62Markdown 501503 Definiciones

git-sincronizar: un cherry-pick VACÍO no es un fallo, es que el contenido ya estaba

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>

615cc2f8393c314fa9a02ee119c979c92c026ac5 · por Sergio · (hace 1 mes) · padre 17b6ea1a4 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +15 −4

diff --git a/scripts/git-sincronizar.sh b/scripts/git-sincronizar.sh
index 1a786313..125861d0 100755
--- a/scripts/git-sincronizar.sh
+++ b/scripts/git-sincronizar.sh
@@ -25,6 +25,7 @@
 set -euo pipefail
 cd "$(cd "$(dirname "$0")/.." && pwd)"
 
+TMPERR=$(mktemp); trap 'rm -f "$TMPERR"' EXIT
 MIO=$(git rev-parse HEAD)
 MSG=$(git log -1 --format=%s "$MIO")
 echo "==> mi HEAD: ${MIO:0:9} · $MSG"
@@ -39,10 +40,20 @@ else
   if git log --oneline -20 | grep -qF "$MSG"; then
     echo "    ✓ el commit sobrevivió al rebase"
   else
-    echo "!!  EL COMMIT DESAPARECIÓ del árbol tras el rebase — recuperando desde el reflog"
-    git cherry-pick "$MIO"
-    git log --oneline -1 | grep -qF "$MSG" || { echo "!!  no pude recuperarlo; mirá 'git reflog'"; exit 1; }
-    echo "    ✓ recuperado"
+    echo "!!  el commit no aparece en los últimos 20 tras el rebase — intento recuperarlo"
+    # ⚠ `cherry-pick` puede salir con «the previous cherry-pick is now empty»: eso NO es un fallo,
+    # es que el CONTENIDO ya estaba en el árbol (la comprobación por mensaje puede errar cuando el
+    # rebase lo dejó más atrás de 20 commits, o cuando otro agente lo trajo por su lado). Se aborta
+    # el cherry-pick y se sigue: lo que importa es que el contenido esté, no que el sha coincida.
+    if git cherry-pick "$MIO" 2>"$TMPERR"; then
+      echo "    ✓ recuperado"
+    elif grep -q "now empty\|nothing to commit" "$TMPERR"; then
+      git cherry-pick --abort 2>/dev/null || true
+      echo "    ✓ el contenido ya estaba (cherry-pick vacío): falso positivo de la comprobación"
+    else
+      git cherry-pick --abort 2>/dev/null || true
+      echo "!!  no pude recuperarlo. Está en el reflog:"; git reflog -8 | sed "s/^/      /"; exit 1
+    fi
   fi
 fi