From e13c8f395a4803f6ceb37b32c5648a0346d3f6e3 Mon Sep 17 00:00:00 2001 From: Victor Cordero Date: Fri, 11 Sep 2026 00:01:57 -0600 Subject: [PATCH] =?UTF-8?q?docs(update):=20-X=20theirs=20borra=20el=20trab?= =?UTF-8?q?ajo=20de=20quien=20extendi=C3=B3=20Forja?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El Paso 5 manda `git merge upstream/main -X theirs` (y lo ofrece también como "camino más simple" con `git pull`). Para un miembro que nunca tocó el motor está bien. Para cualquiera que haya extendido Forja —lo que el propio repo invita a hacer en CONTRIBUTING.md y en la sección "Forja es tuyo, extiéndelo" del skill del agente— es destructivo: `-X theirs` entrega a upstream TODO hunk en conflicto, así que se lleva su código sin marcar un conflicto ni dejar rastro de lo que descartó. El Paso 4 no alcanza a atraparlo: revisa `git status --porcelain src/`, o sea solo cambios SIN COMMITEAR. Un fork con su trabajo ya commiteado pasa ese paso "en limpio" y entra directo al `-X theirs`. Y el respaldo automático que se agregó después vive en el CLI (`forjabot update`), no en esta ruta de git. Cambios: - Paso 5 ahora bifurca según `git log ..HEAD -- src/ test/`: sin commits propios, el `-X theirs` de siempre; con commits propios, merge sin estrategia, resolver conflicto por conflicto y usar la suite como red. - Nota nueva: un merge sin conflictos no garantiza que el comportamiento se conservó. Git marca choques de texto, no de intención. Se incluye el `comm` de los archivos tocados por ambos lados, que son los que hay que leer a mano. Solo documentación del skill: no toca código ni tests. --- skill/actualizar-mi-bot.md | 45 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/skill/actualizar-mi-bot.md b/skill/actualizar-mi-bot.md index a497fac6..9feef626 100644 --- a/skill/actualizar-mi-bot.md +++ b/skill/actualizar-mi-bot.md @@ -131,11 +131,34 @@ git status --porcelain src/ La estrategia: traer `upstream/main`, aceptar lo nuevo en `src/` y el resto, pero **siempre conservar el `member/` del miembro**. +**Antes de elegir el comando, averigua si esta instalación tiene código propio +en `src/` ya commiteado** (no solo sin guardar — eso es el Paso 4): + ```bash -# 1) Asegura que member/ no se pierda: marca la carpeta como "siempre mía" -git merge upstream/main --no-edit -X theirs +git log --oneline $(git merge-base HEAD upstream/main)..HEAD -- src/ test/ ``` +- **No devuelve nada** (el caso normal: el miembro nunca tocó el motor) → + usa el camino cómodo: + + ```bash + git merge upstream/main --no-edit -X theirs + ``` + +- **Devuelve commits** (alguien extendió Forja: un canal nuevo, una tool, un + fix propio) → **NO uses `-X theirs`**. Esa opción entrega a upstream TODO + hunk en conflicto, así que se lleva ese trabajo sin avisar y sin dejar + rastro. Mergea sin estrategia y resuelve conflicto por conflicto: + + ```bash + git merge upstream/main # sin -X: los conflictos se marcan y se resuelven + pnpm test && pnpm typecheck # la suite es la red de seguridad + ``` + + Si son muchos conflictos, avísale al miembro que esto es trabajo de + revisión, no un comando: se resuelve archivo por archivo, quedándose con lo + suyo donde upstream no aporta nada y adoptando lo de upstream donde sí. + Si el merge marca conflictos en `member/`, **resuélvelos siempre a favor del miembro** (la versión local): ```bash git checkout --ours -- member/ @@ -151,6 +174,24 @@ git commit --no-edit Verifica que `member/` siga intacto comparándola contra antes del merge (debe estar sin cambios respecto a lo que el miembro tenía). +> ⚠️ **Un merge sin conflictos NO garantiza que el comportamiento se conservó.** +> Git marca los choques de TEXTO, no los de intención: si upstream cambió el +> mismo comportamiento en otro lugar del archivo (o en otro archivo), el merge +> entra limpio y el cambio se aplica igual. Después de mergear, y sobre todo si +> el miembro tenía código propio, revisa a mano los archivos que cambiaron de +> los dos lados: +> +> ```bash +> git diff --name-only $(git merge-base HEAD@{1} upstream/main) HEAD@{1} > /tmp/mios.txt +> git diff --name-only $(git merge-base HEAD@{1} upstream/main) upstream/main > /tmp/upstream.txt +> comm -12 <(sort /tmp/mios.txt) <(sort /tmp/upstream.txt) +> ``` +> +> Esos son los archivos donde hay que leer el resultado, no solo confiar en que +> compiló. Los tests ayudan, pero un test verde tampoco prueba que el +> comportamiento que el miembro quería sigue ahí — solo que no se rompió lo que +> estaba cubierto. + ## Paso 6 — Reinstalar dependencias si cambiaron Solo si cambió `package.json` o `pnpm-lock.yaml`: