El libro se puede descargar aquí
Se podría resolver como lo hemos hecho hasta ahora. Se comienza a trabajar en el UB24 :
Ahora consideramos el dML:
dML: Hay una nueva condición que verifica que el color esté definido (línea 17). Si no existe, cae en el bloque else (líneas 20-22). Las líneas preexistentes se colocaron dentro del condicional y se ajustó su indentación por esa razón (líneas 18-19). Primero, copiemos esas líneas desde el LB hacia el UB.
Casi lo tenemos. Pero hay un problema: Como copiamos el contenido verbatim, perdimos la línea del UB donde se estaba cambiando la frase para incluir el color original. Miren el UB antes de comenzar a resolver de nuevo (línea 11):
Ok, entonces debemos poder reemplazar la línea donde colocamos el valor desde el diccionario y con eso estaría bien: 25
Eso tampoco es correcto. Ahora se pierde la llamada a upper() que viene del LB. Así que no podemos copiar cambios verbatim de un bloque al otro? Todo depende de lo que se traten los cambios. En este caso la línea está recibiendo cambios por las dos ramas así que debemos considerar la intención de ambas, no los cambios literales.
Comencemos a resolver el conflicto desde el principio, en el UB:
El dML (paso 2) no ha cambiado. Una nueva condición se agregó y la copiamos en el paso 3:
Necesitamos ajustar la indentación de las lineas como se hizo en la otra rama:
Agregamos la llamada a upper():
Agregamos el bloque else:
Y ahora llegamos a la solución del conflicto. Remuevan las otras partes del conflicto y los marcadores:
Pero entonces, si no podemos copiar código de una rama a la otra, como hacemos el trabajo? El truco es replicar los cambios que fueron incluidos en el dML y colocarlos en el UB, no copiar los cambios.
Este trabajo donde se debe analizar cuidadosamente lo que ha cambiado (palabra por palabra, espacio por espacio, tab a tab, paréntesis a paréntesis, condicional a condicional) debe ser hecho en cada uno de los conflictos a los que se enfrenten. Me encantaría darles un truco para pode hacer este trabajo más sencillo... pero no lo hay. Una herramienta valiosa que podrían utilizar bajo ciertas circunstancias es usar git diff –color-words para comparar el ancestro común con las ramas... o incluso las ramas entre ellas: 26
Cuando las personas deciden no hacer este trabajo exhaustivamente, fácilmente se escapan detalles de las ramas involucradas (o se copia cambios verbatim borrando otros cambios) y eso es lo que eventualmente podría reventar tiempo después, algunas veces de forma GRANDE.... ESPECTACULAR... FULGURANTE.... en producción. Ciertamente no el mejor sitio para enterarse de que no se trajo un cambio en un merge hace algunas semanas o meses.
Si se agrega código a una rama, probablemente debería quedar en el código resultante, justo como hicimos con la sección else 27. Y el código borrado es un caso especial que debe ser analizado cuidadosamente por lo que estaré abordándolo más adelante.
Del repo de git, hagan checkout de la revisión d9d65e9f6a y hagan merge de b57e8119e6. 28 La solución está aquí.
Del repo de git, hagan checkout de la revisión cf054f817a y hagan merge de caf388caa1. 29 La solution está aquí.
Copyright 2020 Edmundo Carmona Antoranz