Fixing up earlier commits with git history

Anyone who has polished a commit series before sending it for review has probably had this experience: you notice that a change in your working tree really belongs in an earlier commit, not at the tip of the branch. Today, one common way to handle that is to create a fixup commit and then autosquash it: $ git commit --fixup= $ git rebase --autosquash ^ That works, but it asks you to spell out the mechanism instead of the intent. Git 2. 55 builds on the experimental git history command, which Git 2. 54 introduced, by adding a new fixup subcommand.

It applies the changes currently staged in the index to an earlier commit: Here is a small example. The first commit introduced a pancake recipe, followed by a few more commits on top. Later, we realize that the recipe was missing maple syrup. After staging that one-line change, git history fixup folds it into the original recipe commit and replays the descendant commits on top. Here the staged change becomes part of the target commit itself.

The target commit keeps its message and authorship by default, unless you pass --reedit-message, and Git rewrites the commits that follow so the branch ends at an equivalent history with the fix in the right place. Like the rest of git history, this command is still experimental. It is also intentionally conservative. Because fixup reads from the index, it needs a working tree and cannot operate in a bare repository; if applying the staged change would produce a conflict, the command aborts instead of leaving you in the middle of a stateful rewrite.