git history reword <commit> [--dry-run] [--update-refs=(branches|head)] git history split <commit> [--dry-run] [--update-refs=(branches|head)] [--] [<pathspec>…]
Rewrite history by rearranging or modifying specific commits in the history.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
This command is related to linkgit:git-rebase[1] in that both commands can be used to rewrite history. There are a couple of major differences though:
-
linkgit:git-history[1] can work in a bare repository as it does not need to touch either the index or the worktree.
-
linkgit:git-history[1] does not execute any linkgit:githooks[5] at the current point in time. This may change in the future.
-
linkgit:git-history[1] by default updates all branches that are descendants of the original commit to point to the rewritten commit.
Overall, linkgit:git-history[1] aims to provide a more opinionated way to modify your commit history that is simpler to use compared to linkgit:git-rebase[1] in general.
Use linkgit:git-rebase[1] if you want to reapply a range of commits onto a different base, or interactive rebases if you want to edit a range of commits at once.
This command supports two-parent merge commits in the rewrite path: the auto-remerged tree of the original parents, the merge commit itself, and the auto-merged tree of the rewritten parents are combined so that the user’s manual conflict resolution (textual or semantic) is preserved through the replay. Octopus merges (more than two parents) are not supported and are rejected with an error.
When only one of the two parents of a merge has been rewritten, it is possible for the rewritten parent and the unchanged parent to conflict on a region that the original parents did not conflict on. The user’s original resolution of the merge cannot speak to such a fresh conflict because it never existed at the time the merge was made. In that situation the replay stops and reports a conflict on the affected path rather than silently committing a tree whose content is taken from the rewritten side. Resolve the new conflict the same way you would resolve any other merge conflict, then continue. Paths managed by a binary, custom, or other non-textual merge driver are treated the same way: a fresh inner conflict on such a path is surfaced, never absorbed.
The replay propagates the textual diffs the user actually made in the merge commit. It does not extrapolate symbol-level intent: if rewriting the parents pulls in genuinely new content (for example, a new caller of a function that the merge renamed), that new content is not rewritten by the replay and may need a follow-up edit. Symbol-aware refactoring is out of scope here, just as it is for plain rebase.
The command does not support operations that can result in merge
conflicts on the replayed merge itself. This limitation is by design
as history rewrites are not intended to be stateful operations. Use
linkgit:git-rebase[1] with the --rebase-merges flag when the
rewrite is expected to require interactive conflict resolution.
The following commands are available to rewrite history in different ways:
reword <commit>-
Rewrite the commit message of the specified commit. All the other details of this commit remain unchanged. This command will spawn an editor with the current message of that commit.
split <commit> [--] [<pathspec>...]-
Interactively split up <commit> into two commits by choosing hunks introduced by it that will be moved into the new split-out commit. These hunks will then be written into a new commit that becomes the parent of the previous commit. The original commit stays intact, except that its parent will be the newly split-out commit.
The commit messages of the split-up commits will be asked for by launching the configured editor. Authorship of the commit will be the same as for the original commit.
If passed, <pathspec> can be used to limit which changes shall be split out of the original commit. Files not matching any of the pathspecs will remain part of the original commit. For more details, see the pathspec entry in linkgit:gitglossary[7].
It is invalid to select either all or no hunks, as that would lead to one of the commits becoming empty.
--dry-run-
Do not update any references, but instead print any ref updates in a format that can be consumed by linkgit:git-update-ref[1]. Necessary new objects will be written into the repository, so applying these printed ref updates is generally safe.
--update-refs=(branches|head)-
Control which references will be updated by the command, if any. With
branches, all local branches that point to commits which are descendants of the original commit will be rewritten. Withhead, only the currentHEADreference will be rewritten. Defaults tobranches.
$ git log --stat --oneline 3f81232 (HEAD -> main) original bar | 1 + foo | 1 + 2 files changed, 2 insertions(+) $ git history split HEAD diff --git a/bar b/bar new file mode 100644 index 0000000..5716ca5 --- /dev/null +++ b/bar @@ -0,0 +1 @@ +bar (1/1) Stage addition [y,n,q,a,d,p,?]? y diff --git a/foo b/foo new file mode 100644 index 0000000..257cc56 --- /dev/null +++ b/foo @@ -0,0 +1 @@ +foo (1/1) Stage addition [y,n,q,a,d,p,?]? n $ git log --stat --oneline 7cebe64 (HEAD -> main) original foo | 1 + 1 file changed, 1 insertion(+) d1582f3 split-out commit bar | 1 + 1 file changed, 1 insertion(+)