Git rebase does not destroy history, it just does not link it together. That might be a bad thing. But the individual commits all making an appearance on the destination branch is a good thing.
From those who favor merge, what is bad is that there are no second parent pointers tracking where those changes came from.
This coulid be obtained by reimplementing git rebase as a sequence of merges. Git rebase is a sequence of zero or more cherry picks, not merges. If git rebase merged each commit instead of cherry picking, each commit would have a parent pointing to its original.
In a git bisect, there would be no need to chase those second parents; you would be looking for which merged commit introduced the breakage, and not care about its original, except in some rare situations where you want to analyze more deeply what went wrong (and then that parent pointer would be a bit handy).
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.
Clean history can exist with merges, but I think merging all over the place obviously encourages messy behaviors.
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.
Git usage is only one part of a wider engineering org. That like saying "bugless code is objectively better" without considering time to delivery, engineering resources, etc.
