4 ms·

It always seemed like a needless complexity when you can just merge and get the same result in terms of the state of the files, just with a different commit his

It always seemed like a needless complexity when you can just merge and get the same result in terms of the state of the files, just with a different commit history. The only time it might make sense if you are following some arbitrary strict style guidelines for commits. Some people care more about the commit history than others, not that either way is necessarily better.

wakawaka28 2y ago
A linear commit history is objectively better. But whether it's worth the effort to maintain is up to you to decide. If your branches don't stay unmerged for long, then you're probably better off rebasing instead of generating tons of little branches for no reason.
- hansonkd 2y ago
  Objectively better to what? 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.
  - rontdrr2 2y ago
    [dead]
  - wakawaka28 2y ago
    Better to work with of course. If you have valid reasons to have branches, such as a need to ship multiple versions, I don't have a problem with that. But day-to-day work is better done via rebasing rather than making a ton of public branches that get merged. If you know what you're doing then rebasing is just as easy as merging. As others have said, git rerere helps a lot too.
- lmm 2y ago
  > 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 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.
- kazinator 2y ago
  The linear part of the history is objectively better than if that same change were collapsed into a single patch bomb. 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).
nh2 2y ago
git bisect. I have a friend, he thought rebasing for linear history was not worth the effort. I told him to do it, because I once had to find a regression over thousands of commits in a merge-heavy code base and it took days. He was not convinced. Then he had to find a regression. It took over a month. With git bisect's binary search, it would have taken half a day. My friend now rebases.
- samatman 2y ago
  I don't understand why this would make a difference. Any given snapshot has a linear history, so it should be as bisectable as the rebased equivalent. What am I missing here?
  - Arelius 2y ago
    Agreed… I think people like to think bisect doesn’t work with merges also.
  - nh2 2y ago
    > Any given snapshot has a linear history Not sure what you mean. The key thing of merges is that they... merge... two histories. A git history graph tool shows that clearly then. A bisection has to choose whether to go left or right.
- lmm 2y ago
  bisect works much better with merge than it does with rebase (with rebase it's easy to end up with a long chain of commits that don't compile, so your automated bisect script doesn't work).
  - nh2 2y ago
    Of course all your commits need to compile and pass tests. It didn't even occur to me that anybody would permit that in their CI. If you check in commits that don't compile then you can't use automatic bisection effectively (it still does work if that happens rarely, thanks to automatic `git bisect skip`). Of course every non-building commit will make bisecting a merge history a pain even more, not sure why you think it to be better with merges than with linear history.

wakawaka28 2y ago

A linear commit history is objectively better. But whether it's worth the effort to maintain is up to you to decide. If your branches don't stay unmerged for long, then you're probably better off rebasing instead of generating tons of little branches for no reason.

hansonkd 2y ago
Objectively better to what? 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.
- rontdrr2 2y ago
  [dead]
- wakawaka28 2y ago
  Better to work with of course. If you have valid reasons to have branches, such as a need to ship multiple versions, I don't have a problem with that. But day-to-day work is better done via rebasing rather than making a ton of public branches that get merged. If you know what you're doing then rebasing is just as easy as merging. As others have said, git rerere helps a lot too.
lmm 2y ago
> 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 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.
kazinator 2y ago
The linear part of the history is objectively better than if that same change were collapsed into a single patch bomb. 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).

nh2 2y ago

git bisect. I have a friend, he thought rebasing for linear history was not worth the effort. I told him to do it, because I once had to find a regression over thousands of commits in a merge-heavy code base and it took days. He was not convinced. Then he had to find a regression. It took over a month. With git bisect's binary search, it would have taken half a day. My friend now rebases.

samatman 2y ago
I don't understand why this would make a difference. Any given snapshot has a linear history, so it should be as bisectable as the rebased equivalent. What am I missing here?
- Arelius 2y ago
  Agreed… I think people like to think bisect doesn’t work with merges also.
- nh2 2y ago
  > Any given snapshot has a linear history Not sure what you mean. The key thing of merges is that they... merge... two histories. A git history graph tool shows that clearly then. A bisection has to choose whether to go left or right.
lmm 2y ago
bisect works much better with merge than it does with rebase (with rebase it's easy to end up with a long chain of commits that don't compile, so your automated bisect script doesn't work).
- nh2 2y ago
  Of course all your commits need to compile and pass tests. It didn't even occur to me that anybody would permit that in their CI. If you check in commits that don't compile then you can't use automatic bisection effectively (it still does work if that happens rarely, thanks to automatic `git bisect skip`). Of course every non-building commit will make bisecting a merge history a pain even more, not sure why you think it to be better with merges than with linear history.