2.2 Some conflict

Let’s see what happens when there are conflicts. Checkout example9/branchB and merge example9/branchA:

We can see that example.py is showing up in Unmerged paths, and module.py is listed in Changes to be committed. .gitignore is not listed. .gitignore hasn’t changed between HEAD, index and what we have in the working tree so nothing to report on it. module.py has changed as part of the merge process without any conflicts and that’s why it is present in HEAD and in index with different ids. The file currently on the working tree is just like it is on index and that’s why the file is listed in Changes to be committed. The interesting stuff is on example.py. Instead of having a single item for it in index, there are 3 and each one of them has a different index stage number. When there is content conflict on a file (like in this case), git will hold 3 versions of the file in index. Stage number 1 is the file as it is in the common ancestor⁶ . Stage number 2 is the file as it is in HEAD. Stage number 3 is the file as it is in the other branch. See for yourselves:

Stage number 0, as we had seen before, means that the file is either unchanged or added to index.

Let’s solve the conflict as we had done before (which means that both files have to be modified) and then let’s see the output of the git commands:

Even though the ids of the objects in index and HEAD hasn’t changed, the content of the files has changed on the working tree. Given that module.py has an id that is different between index and HEAD, git lists it in Changes to be committed. Given that the content of the file on the working tree is different from index, it is also listed in Changes not staged for commit. example.py hasn’t been added to index and so it is still conflicted so we still have the same 3 versions of the file in index and is listed in Unmerged paths.

Let’s add module.py first and see what happens:

For this file, it behaved like it did when there was no conflict. The ids for the object are different between HEAD and index and that’s why it is listed in Changes to be committed. The file in the working tree is like it is in index now and that’s why git knows there’s nothing else to report about the file. example.py is still conflicted and so there are no changes for it from what we had seen before.

Let’s add example.py now:

Now that the (originally) conflicted file has been added to index, we have a single item for it in index. Given that the ids are not the same between HEAD and index, git reports it in Changed to be committed and given that the content of the files in the working tree is the same as it is in index, git doesn’t say anything else about the files. Let’s create a new revision at this moment and see what happens:

As it had happened before when there was no conflict, when we create a new revision, the ids in HEAD are updated to the same ids of the objects that index had right before the revision was created. Given that now index and HEAD have the same ids, there are no Changes to be committed and given that there are no differences between index and working tree, there’s nothing else to report.

If you stop to think about it, other than having the 3 items listed in index while the file was conflicted, there were no other differences in terms of what was held in index and the revisions. All in all, git does not save any information whatsoever related to the conflicts that happened on a merge when a new revision is created. It simply creates a new revision with multiple parents and the files and their (final) contents on the revision just like it would do on any other revision:

Copyright 2020 Edmundo Carmona Antoranz