git-merge stages

Gergely Polonkai
Oct 4, 2016 :: 12:46

This was a mail to my company’s internal Git mailing list, after I realised many colleagues can’t wrap their heads around merge conflicts.

Hello all,

I just saw this on the git-users list and thought it could help you when you bump into a merge conflict. It is an excerpt from a mail by Konstantin Khomoutov (one of the main contributors on the list), with a few modifications of mine. Happy debugging :)

When a merge conflict is detected for a file, Git:

  1. Updates the entry for that file in the index to make it contain several so-called “stages”:
    • 0: “Ours” version – that one which was there in this index entry before we begun to merge. At the beginning of the conflict, like right after the git merge or git rebase command this won’t exist (unless you had the file in the index, which you didn’t, did you?). When you resolve the conflict and use git add my/conflicting/, this will be the version added to the staging area (index), thus, the resolution of the conflict.
    • 1: The version from the common ancestor commit, ie. the version of the file both of you modified.
    • 2: The version from HEAD. During a merge, this is the current branch. During a rebase, this is the branch or commit you are rebasing onto, which usually will be origin/develop).
    • 3: The version being merged, or the commit you are rebasing.
  2. Updates the file in the work tree to contain conflict markers and the conflicting chunks of text between them (and the text from the common ancestor if the diff3 style of conflict markers was set).

Now you can use the numbers in point 1 to access the different stages of the conflicting file. For example, to see the common ancestor (the version both of you modified), use

git show :1:my/conflicting/

Or, to see the difference between the two conflicting versions, try

git diff :2:my/conflicting/ :3:my/conflicting/

Note that you can’t use the :0: stage before you stage your resolution with git add, and you can’t use the :2: and :3: stages after you staged the resolution.

Fun fact: behind the scenes, these are the files (revisions) git mergetool accesses when it presents you the conflict visually.

comments powered by Disqus

Gergely Polonkai is a systems engineer of a telco company, and also a freelancer self- and software developer.

He is learning about different IT subjects since the late 1990s. These include web development, application building, systems engineering, IT security and many others. He also dug his nose deeply into free software, dealing with different types of Linux and its applications, while also writing and contributing to some open source projects.

On this site he is writing posts about different stuff he faces during work (oh my, yet another IT solutions blog), hoping they can help others with their job, or just to get along with their brand new netbook that shipped with Linux.

“I believe one can only achieve success if they follow their own instincts and listen to, but not bend under others’ opinions. If you change your course just because someone says so, you are following their instincts, not yours.”