Smarter rebase avoiding redundant work?

Why not squash the redundant patches together in an initial interactive rebase (first re-order them so they are together) so that you have cleaned out the 'modify then delete' aspects of the sequence. You can be selective with the hunks within a commit during this stage (e.g. using git gui). This would then give you a better sequence for a final clean rebase.

You want to use git rerere combined with teaching the rerere database from historical commits using rerere-train.sh (you may already have it at /usr/share/doc/git/contrib/rerere-train.sh). This allows git to automatically use merge conflict resolutions learned from the history.

Warning: you're basically making git rewrite the source code by blindly using historical string replacements to fix the conflicting merge. You should review all conflicting merges after the rebase. I find that gitk works fine for this (it will show only conflict resolution as the patch for merges). I've had only good experiences with rerere, you might not be that lucky. Basically, if your history does contain broken merges (that is, merges that are technically incorrectly done and then later fixed in following commits), you do not want to use rerere from the history, unless you want to have similarly broken merges done automatically for you.

Long story short, you just run

git config --global rerere.enabled 1
bash /usr/share/doc/git/contrib/rerere-train.sh --all

followed by the rebase you really want to do and it should just magically work.

After you have enabled rerere globally, you no longer need to learn from the history in the future. The learning feature is required only for using rerere after the fact the conflict resolution is already done before enabling rerere.

PS. I found similar answer to another question: https://stackoverflow.com/a/4155237/334451

You could use git rerere feature.

You have to enable it using git config --global rerere.enabled 1, after that, every conflict you resolve get stored for later use and the resolution is reapplied in the same contexts.

You can check the stored resolutions with git rerere diff.

Take a look at this tutorial for more information.