[ngruhn]

Maintaining linear history is arguably more work. But excessively non-linear history can be so confusing to reason over.

Linear history is like reality: One past and many potential futures. With non-linear history, your past depends on "where you are".

    ----- M -----+--- P
                /
    ----- D ---+

Say I'm at commit P (for present). I got married at commit M and got a dog at commit D. So I got married first and got a Dog later, right? But if I go back in time to commit D where I got the dog, our marriage is not in my past anymore?! Now my wife is sneezing all the time. Maybe she has a dog allergy. I go back in time to commit D but can't reproduce the issue. Guess the dog can't be the problem.

[hnarn]

> 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]

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

[fc417fc802]

You omitted the merge commit. M is taken so let's go with R. You jump back to M to confirm that the symptoms really don't predate the marriage. Then you jump to R to reproduce and track down the underlying cause of the bad interaction.

Had you simply rebased you would have lost the ability to separate the initial working implementation of D from the modifications required to reconcile it with M (and possibly others that predate it). At least, unless you still happen to have a copy of your pre-rebase history lying around but I prefer not to depend on happenstance.

[ngruhn]

> Had you simply rebased you would have lost the ability to separate the initial working implementation of D from the modifications required to reconcile it with M

I'd say: cleaning that up is an advantage. Why keep that around? It wouldn't be necessary if there was no update on the main branch in the meantime. With rebase you just pretend you started working after that update on main.

[javier123454321]

Until you commit to trunk, you haven't gotten the dog. You're proposing getting a dog. The action of getting the dog happens at merge to trunk. That's when history is created.

[psychoslave]

That’s also because there are multiple concerned that are tried to be presented as the same exposed output through a common feature. Having one branch that provides a linear logical overview of the project feature progression is not incompatible with having many other branches with all kind of messes going back and forth, merging and forking each other and so on.

In my experience, when there is a bug, it’s often quicker to fix it without having a look at the past commits, even when a regression occurs. If it’s not obvious just looking at the current state of the code, asking whoever touch that part last will generally give a better shortcut because there is so much more in the person mind than the whole git history.

Yes logs and commit history can brings the "haha" insight, and in some rare occasion it’s nice to have git bisect at hand.

Maybe that’s just me, and the pinnacle of best engineers will always trust the source tree as most important source of information and starting point to move forward. :)