title: How does a Git merge commit know which is the "real" parent?
body: <p>As I understand it, Git figures out the current state of a repository by tracing back the changes from the current HEAD through its parents to the root.</p>
  
  <p>Merge commits have two parents, like <code>C6</code> here:</p>
  
  <p><img src="https://i.stack.imgur.com/BiW2P.png" alt="Merge commit example from git-scm book"></p>
  
  <p><sup><a href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging" rel="nofollow noreferrer">[source]</a></sup></p>
  
  <p>I understand the advantages, rationale, etc. for having multiple parents like this.</p>
  
  <p>However, I don't understand how you could trace back through the history here. If your head is on the tip of the <code>master</code> branch, and you trace back one commit at a time, how does Git know that <code>C6</code>'s &ldquo;real&rdquo; parent is <code>C5</code>? Is it just something like the order they're stored in the commit file?</p>
  
  <p>Or am I misunderstanding something? Is this not what Git does at all?</p>