2.2 Un conflicto

Veamos lo que sucede cuando hay un conflicto. Hagamos checkout de example9/branchB y mezclemos example9/branchA:

Podemos ver que example.py aparece en Unmerged paths, y module.py está listado en Changes to be committed. .gitignore no sale listado en git status. .gitignore no ha cambiado entre HEAD, index y lo que está en el árbol de trabajo así que no hay nada que reportar sobre él. module.py cambió como parte del proceso de mezcla sin conflictos y por eso está presente tanto en HEAD como en el index con un id different. El archivo que está actualmente en el árbol de trabajo es justo como está en el index y por eso sale listado en Changes to be committed. Lo interesante es con respecto a example.py. En vez de tener un solo ítem del archivo en el index, hay 3 y cada instancia tiene un index stage diferente del 1 al 3. Cuando hay un conflicto de contenido en un archivo (como en este caso), git va a guardar 3 versiones del archivo en el index. Stage número 1 es el archivo como está en el ancestro común⁶ . Stage número 2 es el archivo como está en HEAD. Stage número 3 es el archivo como está en la otra rama. Vean por sí mismos:

Stage número 0, como vimos antes, significa que el archivo no tiene cambios o que fue agregado al index.

Resolvamos el conflicto como habíamos hecho antes (lo que significa editar ambos archivos) y entonces veamos la salida de comandos git:

Aunque los ids de los objetos en index y HEAD no han cambiado, el contenido de los archivos cambió en el árbol de trabajo. Dado que module.py tiene un id diferente entre index y HEAD, git lo muestra en Changes to be committed. Dado que el contenido del archivo en el árbol de trabajo es diferente de index, también se lista en Changes not staged for commit. example.py no ha sido agregado al index, así que para git sigue con conflictosy mantiene las 3 versiones en el index y se lista en Unmerged paths.

Agreguemos module.py primero y veamos qué sucede:

Para este archivo, se comporta como sucedía antes cuando no había conflictos. Los ids para este archivo son diferentes are entre HEAD e index y por eso sale listado en Changes to be committed. El archivo en el árbol de trabajo es como está en el index ahora y por eso git no tiene más nada que reportar sobre él. example.py sigue con conflictos y por eso no hay cambios en cuanto a lo que veíamos previamente.

Ahora agreguemos example.py:

Ahora que el archivo que (originalmente) tenía conflictos ha sido agregado, tenemos un solo ítem para él en el index. Dado que los ids no son los mismos entre HEAD e index, git lo reporta en Changed to be committed y dado que el contenido del archivo en el árbol de trabajo es como en el index, git no tiene más nada que decir sobre él. Creemos una nueva revisión en este momento y veamos qué sucede.

Como sucedió anteriormente cuando no había conflictos, cuando se crea una nueva revisión, los ids en HEAD son actualizados a los mismos ids del index⁷ . Dado que index y HEAD tienen los mismos ids, no hay nada listado en Changes to be committed y dado que no hay diferencias entre el index y el arbol de trabajo, no hay más nada que reportar.

Si se detienen a pensarlo, aparte de los 3 items listados en index mientras el archivo tenía conflictos, no hay otras diferencias en cuanto a lo que se guardó en index o en las revisiones. Dentro de todo, git no guarda ninguna información sobre los archivos que tuvieron conflictos cuando se crea una revisión. Simplemente crea una nueva revisión con sus múltiples padres, los archivos y sus contenidos (finales) justo como en cualquier otra revisión:

Copyright 2020 Edmundo Carmona Antoranz