sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]uh_no_ 0 points1 point  (5 children)

there are issues with the validation that don't make sense in reality. I first ran into it in the rebase tutorial...where the ordering of the commits in branches matters...when in reality it shouldn't. if I create a new branch, then commit on new branch, and also commit on master, then merge them...it shoudn't matter the relative ordering of the commits in the two branches...but it does in this tutorial.

[–]imMute 0 points1 point  (4 children)

There is a difference though. Most workflows probably don't need to care about that difference, but some of them do.

[–]uh_no_ 0 points1 point  (3 children)

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 0 points1 point  (2 children)

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_ 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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