My only beef with rebasing is that it seems to fail much more often, whereas merges will usually do the right thing. I realize this is git-specific, but rebases have still given me much more trouble than merges.
I do sometimes have to rebase across thousands of commits because I let a branch rot, and that can be hard to rebase, but it can be equally difficult to merge. Instead I use a bisecting rebase approach where I try to rebase straight to the new upstream, and if there's conflicts, abort the rebase and try rebasing to halfway to the new upstream, continuing the process until the rebase was across just one commit, thus I can resolve conflicts directly with the upstream commit that caused them, then restart the process until done.
Merging doesn't have that problem, it usually just merges fine unless there are conficts in the latest commit (not all previous ones).
is this solved by enabling git-rerere ?
https://medium.com/@porteneuve/fix-conflicts-only-once-with-...
Also, with this script you get to see which of your commits is conflicting with which upstream commits. That's really important information to me.
I'd really like git to have this feature built-in to it...
One can implement that even with Fossil or any other VCS that pretends it does not implement rebase and pretends it never will.
(Viktor here is https://github.com/vdukhovni/, and I did heavily alter that code.)
Thanks for the gist