I don't really buy the commutative patch thing either (yet!), but I'm willing to believe that it's because I'm so happy to `git rebase` all the time, but also b

I don't really buy the commutative patch thing either (yet!), but I'm willing to believe that it's because I'm so happy to `git rebase` all the time, but also because I have a tool for fast rebasing across many commits[0]. > The solution that he writes up is basically "git merge" and part of the reason that we have such a bad time with git is that the industry largely standardized on "git rebase", [...] I wish. So many people still use `git merge` workflows! > No git rerere: rerere is a hack to try to make rebase pretend that it doesn't drop usable merge information on the floor, if you stop imposing rebase on yourself you don't need the rerere hack. Whether you cherry-pick (rebase) or merge, you still only commit the conflict-resolved state. Merge commits document what were the two HEADs you conflict-resolved, but so what, if you lose the merge commits at upstream integration time no one loses anything useful. I've worked on very large systems using rebase workflows. I have written about that many times here on HN in the comments. Rebase workflows are definitely far better than merge workflows. Perhaps the Jujutsu approach to rebase (automate it!) is the right solution for all those who can't stand rebasing. [0] https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...