How does a Git merge commit know which is the “real” parent?

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.

Merge commits have two parents, like C6 here:

  • Add a directory which previously had its own git repository
  • How to get a list of all blobs in a repository in Git
  • How does Git store tree objects?
  • Published using capistrano, is it possible to know which version is running using GIT? or anything?
  • update local github account information
  • Comparing differences across a rebase in Git
  • Merge commit example from git-scm book

    [source]

    I understand the advantages, rationale, etc. for having multiple parents like this.

    However, I don’t understand how you could trace back through the history here. If your head is on the tip of the master branch, and you trace back one commit at a time, how does Git know that C6‘s “real” parent is C5? Is it just something like the order they’re stored in the commit file?

    Or am I misunderstanding something? Is this not what Git does at all?

  • cross platform git: possible strategies to handle platform specific files
  • Git Merge: parallel identical additions are merged without conflict by including the same code block TWICE in the merged file without complaint. Why?
  • Can Gerrit go Out-Of-Sync
  • Is it OK to have a development branch where individual commits may not even be working?
  • How to config git to pull from http and push through ssh in one 'remote'?
  • Visual Studio 2008 - Add Reference
  • One Solution collect form web for “How does a Git merge commit know which is the “real” parent?”

    There’s no such thing as a “real” parent. A merge has multiple parents, could be more than two, and none of them is more real than the other. What you are thinking of is the first parent, and that should give you the answer; parents are ordered.

    Git Baby is a git and github fan, let's start git clone.