Procedimiento: Sincronización con el repo inglés

[joaquinelio]

Comentarios sobre Merge desde repo inglés

• Es un típico pull y no hay sorpresas.
• Magia git: solo muestra las líneas recientemente modificadas en inglés, no el texto entero aunque esté completamente traducido. No percibir esto nos confundió a muchos.
• No sugiero usar el PR del bot, es ajeno a GIT y hay que verificar demasiado.
• Sugiero mantener el SYNC simple y pequeño, y así será simple de incorporar. Ver "delegar" en "notas".
• Respetar SIEMPRE la numeración de líneas y arreglarla si está mal, o "delegar" (notas) su corrección.

Sync LOCAL con ayuda de un IDE

Acá uso VSCode, con gitlens si necesito hacer comparaciones (ver nota "gitlens")
Pongo el camino largo pero claro es lo mismo usar los combinados de pull y checkout.
Asumiendo que ya tenemos fork propio, con remotos origin y upstream:

• agregar como remoto al repo inglés, ej "enstream"

git remote add enstream https://github.com/javascript-tutorial/en.javascript.info.git

• Luego el usual fetch/merge, pero repetimos para el inglés:

git fetch upstream
git fetch enstream

git merge upstream/master

• Creamos branch SuperSync

git branch susy
git checkout susy

• Y merge

git merge enstream/master 

o con salida a archivos log (agreguen los path después del ">" )

git merge enstream/master   1>stdout.log   2>stderr.log

El merge queda detenido en los conflictos:

1. Revisar imágenes SVG
   Si hubo archivos svg traducibles nuevos o actualizados. Nada que hacer aquí, Hay que rehacer el procedimiento de traducción de imágenes, lo que amerita un nuevo issue.
2. Revisar los "staged"
   Suele haber líneas nuevas a traducir, añadidas sin conflicto y perfectamente identificadas por el IDE.
3. Resolver conflictos.
   Easy...
   A veces no: La firme recomendación es mantener el sync corto e incorporarlo rápidamente y postergar el trabajo enun issue. Ver nota "delegar".
4. save, stage, commit, push, PR...
   Qué mortal no hace esto en el desayuno...

That's all folks!

Notas:

Log "CONFLICT (rename/delete):/archivo"

Es el caso en que git decide sobrescribir la version no trackeada de un archivo sin mostrar conflicto ni culpa.
Esto ya fue depurado con el PR #365.
Esto es MUY raro, y peligroso en cualquier proyecto git (recuérdenlo y se ganarán la gloria resolviendolo)
El mecanismo del error fue explicado por @iliakan e inmortalizado en el issue #348
Para abreviar, se agrega a merge un comando para volverlo menos inteligente, evitará algunos automerge pero se podrá seguir con el procedimiento en forma segura.

git merge enstream/master -X no-renames  

Delegar / posponer el trabajo de retraducción

Si un cambio requiere mucho trabajo, requiere también mucha revisión y tiempo, además de la necesidad de verificar todos y cada uno en el sitio online.
Recomiendo firmemente NO demorar el sync y resolver desechando los cambios con la opcion de comando OURS o con ayuda del IDE (en VS Code, botón secundario "accept all current", grabar y poner en stage) y generar un issue para registrar la retraducción como trabajo pendiente.
Quien finalmente lo tome puede ir al repo inglés y ver fácilmente su "history" los últimos commit o en su "BLAME" el registro de cambios (cada línea con fecha de revisión), y tomarse TODO el tiempo necesario para traducción, revisión y chequeo online.
Aclaré BLAME y HISTORY porque para este particular proyecto es mucho más práctico que hacer un DIFF el cual mostraría el archivo entero modificado.

Extensión gitlens para VScode

Es un diff muy flexible, permite comparar nuestro working branch con master enstream y comparar/editar en la misma pestaña.
También es práctico tener dos pestañas en el ide,

• una editable con el article abierto desde source control
• la otra abierta desde gitlens mostrando en color las lineas propia y remota.

PR del BOT

Github no reconoce sus conflictos como propios, figuran como simples añadidos.

• El botón MERGE queda habilitado desde el principio.
• Presumiblemente (no probé) al hacer merge en estas condiciones se agregarían al texto traducido tanto ambas versiones de texto, español e inglés, como los marcadores de control ">>>> ===== <<<<"
• No muestra las herramientas de resolución de conflictos, por lo que hay que editar el archivo entero con lo que pierden las guias de color.

Es difícil mantener los números de línea, importante para la comparación git.
Con cambios grandes se hace difícil rastrearlos todos.
No es posible testear. Por ejemplo, revisar formato MD.
Por eso recomiendo el trabajo local, hacer el viejo y querido pull y editar en un IDE.

[joaquinelio]

Edit: Resuelto. Procedimiento refinado.

Esto fue un parto.
No se como es un parto, pero fue un parto.

Considero que hay que separar tareas.
El UPDATE es MUY FACIL ahora,
pero retraducir articulos enteros al MISMO tiempo no

@vplentinax
Rehice algunos articulos,
por lo menos uno era tuyo, presionado por hacerlo rapido y mal. Era tuyo, tu area y estaba bien, Ilya lo reescribio, creo que lo arruine.

CREO que cuando hay un articulo rescrito, resuelvo poniendo "OURS" ignorando TODAS las correcciones
y de algun modo se marca para reasignarlo...

ideas?

Ademas se separaria el REVIEW
es importante que los syncs se ejecuten RÁPIDO por el tema de los multiples conflictos, ,
el review de un articulo reescrito puede llevar todo el tiempo que se quiera.

[vplentinax]

@joaquinelio No idea...

Meses atrás hubiese investigado más este proceso pero ya tengo trabajos en my real life y poco time para invertir aquí.

😣

[joaquinelio]

ug... ; (
bue, pero me alegro que te mantengas próspera y productiva. ; )

"proceso" no es nada nuevo, un GIT PULL comun y corriente
hoy (arreglado) no rompe nada,

el problema ahora lo tengo con las furiosas correcciones y reescrituras de articulos de Ilya
JA!! Era lo que me atrajo al sitio en primer lugar...

[joaquinelio]

UF

Si resuelvo articulo rescrito con OURS,
entonces quien tome el articulo va a tener que revisarlo entero

...pero puede ir al sitio ingles y ver en el history las ultimas modificaciones...

me estoy convenciendo:

1. Si son pocas lineas, se resuelve conflicto,
2. Si son muchas, va al IDE, resuelve el articulo con OURS y pone un issue con ese articulo para que alguien lo modifique
   puede ser la misma persona, lo importante es NO demorar el sync ni complicar su revision