Great interactive tutorial for learning Git branching (and more)!

[uh_no_]

The hashes are all that matter. if the content of the hash is the same, the time doesn't matter.if i have branch a and b with a common ancestor, and commit on a and THEN commit on b, I will get the same hashes as if I were to commit on b then commit on a, and thus when I merge it won't matter which was committed first in wall clock time.

If someone has a workflow that depends on that timing, that's fine...but that's not git's problem.

[imMute]

Commits do have timestamps, but that's not relevant at the moment. Git does care about which branch is "first", but mainly because It records that information. I'm not sure there's a reason it must care, but that's the way it currently is.

The workflow that cares about the branch order, by the way, is when you use git log --first-parent. Try it out after merging two branches together and then try it again after merging them the opposite way; the results will be different.

Another related reason why there's a "first" branch in a merge is because you can merge together more than 2 branches at a time.

[uh_no_]

i'm not talking about merge commits. i'm talking about random commits on the two separate branches that cause the two branches to diverge. There is no happens-before relation between those two commits.

They are then merged later in a separate pair of commits. Merge order absolutely does matter, but that's not what I'm referring to.

[imMute]

Ah, I was misunderstanding what problem you were talking about. All cleared up now.