[hnben]

> I can give you an example of when I am glad I rebased

I think the question was about situations where you were glad to rebase, when you could have merged instead

[alemanek]

They kind of spoke to it. Rebasing to bring in changes from main to a feature branch which is a bit longer running keeps all your changes together.

All the commits for your feature get popped on top the commits you brought in from main. When you are putting together your PR you can more easily squash your commits together and fix up your commit history before putting it out for review.

It is a preference thing for sure but I fall into the atomic, self contained, commits camp and rebase workflows make that much cleaner in my opinion. I have worked with both on large teams and I like rebase more but each have their own tradeoffs

[rendaw]

You can bring in changes and address conflicts early with merge too, I believe that's GP's point.

[thousand_nights]

i don't think i have ever even looked at what order the commits are, i only care about the diff vs the target branch when reviewing

especially since every developer has a different idea of what a commit should be, with there being no clear right answer

[cryptonector]

That's hard to answer because I only rebase.