> So I got married first and got a Dog later, right?

No. In one reality, you got married with no dog, and in another reality you got a dog and didn't marry. Then you merged those two realities into P.

Going "back in time to commit D" is already incorrect phrasing, because you're implying linear history where one does not exist. It's more like you're switching to an alternate past.

▲

ngruhn 4 hours ago | parent [-]

The point is that it's harder to reason over.

▲

hnarn 4 hours ago | parent | next [-]

I don't really agree that it's harder to reason over in the sense that it's hard to understand the consequences, but I also agree that a linear history is superior for troubleshooting, just like another comment pointed out that single squashed commits onto a main branch makes it easier to troubleshoot because you go from a working state to a non-working state between two commits.

▲

agumonkey 4 hours ago | parent | prev [-]

there are others tricky time issues with staging/prod parallel branching models too, the most recent merge (to prod) contains older content, so time slips .. maybe for most people it's obvious but it caused me confusion a few times to compare various docker images

	▲	fc417fc802 3 hours ago \| parent [-]
		> the most recent merge (to prod) contains older content Can't that also happen with a rebase? Isn't it an (all too easy to make) error any time you have conflicting changes from two different branches that you have to resolve? Or have I misunderstood your scenario?