[lmm]

> A linear commit history is objectively better.

Disagree. You can always flatten a commit graph into a linear history if you want, but you can't restore the original commit graph from a linear history. So preserving the original history is objectively better.

[wakawaka28]

The original history is usually a bunch of garbage. If you need more detail you can rebase as many commits as you like. More detailed history is sometimes a distinct problem. Imagine trying to bisect some spaghetti bowl of commits with merges to find the source of a recurring issue. It would be relatively nonsensical compared to a clean linear history.

Clean history can exist with merges, but I think merging all over the place obviously encourages messy behaviors.

[lmm]

> If you need more detail you can rebase as many commits as you like.

You can't rebase to get back to the original commits, not without knowing what they are.

> Imagine trying to bisect some spaghetti bowl of commits with merges to find the source of a recurring issue.

I do it all the time (well, less so now that I work with a better team where those issues are pretty rare), it's easy, that's the whole point of the git bisect command.

> It would be relatively nonsensical compared to a clean linear history.

Rebased history is much harder to bisect because you often get long chain of commits that don't compile or are otherwise broken.