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
- How to view content of commit-id shown by git rebase?
- git rebasing commit history not being pulled into branches
- Linus talk - Git vs. data corruption?
- git accidentally tracked config file
- What is the best way to version control my SQL server stored procedures?
- How to deploy .gitignored compiled files in Heroku?
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?
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.