On Thu, Oct 3, 2024, at 21:06, Alireza wrote: > Sometimes a clean merge is possible but with a rebase, in-between > commits may raise conflicts in which case a conflict must be resolved > for each commit individually, which is not quite productive and at the > end wouldn't add so much in how the resulting history looks like. > > With a "one-shot" rebase, a conflict (if any) is made based on the > latest revision, then in-between commits approximated based on that > resolution. This way the history can be roughly preserved with the > same amount of effort while still using a rebase rather than merge. How would this compare to using git-rerere(1)? -- Kristoffer Haugsbakk