3 ms·

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

• wakawaka28 2y ago
  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 2y ago
    > 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.