3 ms·
> 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. Th
by hnarn 9mo ago
> 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 9mo agoThe point is that it's harder to reason over.
- hnarn 9mo agoI 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 9mo agothere 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 9mo ago> 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?
- agumonkey 9mo agohmm my experience didn't even require rebase to cause me troubles (but again, it was 90% pebcak). it's possible rebasing can cause time confusion, maybe you can describe in more detail what you had in mind, i cannot guess on my own but i'm curious