[rom1v]

> `git history fixup` fixes an old commit that has something wrong in it, then autorebases all your branches to match.

Simplifying `git rebase -i` is a great idea, but unfortunately, that does not match my workflow.

I always keep an history of my branches. For example, when I develop a feature, the first version of the branch is `myfeature.1`, then `myfeature.2`, and so on. This is useful because I can retrieve an old version when something behaves differently in a newer one. (And no, `git reflog` will not help)

This has saved me multiple times. For example, I can determine that a problem was introduced between `myfeature.58` and `myfeature.59`. If the "feature" contains 15 commits, I do:

    git range-diff myfeature.58~15..myfeature.58 myfeature.59~15..myfeature.59

This lets me see the changes between the 2 versions, commit by commit (even if they don't have the same base).

I don't want all the branches containing a commit to be rebased automatically (I already try using tags for old versions instead, but this does not quite fit).