From 0ee71f4bd035db61342c2c5a25984e4545347c11 Mon Sep 17 00:00:00 2001 From: Phillip Wood Date: Thu, 18 Dec 2025 16:50:26 +0000 Subject: replay: drop commits that become empty If the changes in a commit being replayed are already in the branch that the commits are being replayed onto, then "git replay" creates an empty commit. This is confusing because the commit message no longer matches the contents of the commit. Drop the commit instead. Commits that start off empty are not dropped. This matches the behavior of "git rebase --reapply-cherry-pick --empty=drop" and "git cherry-pick --empty-drop". If a branch points to a commit that is dropped it will be updated to point to the last commit that was not dropped. This can be seen in the new test where "topic1" is updated to point to the rebased "C" as "F" is dropped because it is already upstream. While this is a breaking change, "git replay" is marked as experimental to allow improvements like this that change the behavior. Helped-by: Elijah Newren Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano --- Documentation/git-replay.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/git-replay.adoc b/Documentation/git-replay.adoc index 4c61f3aa1f..dc966486ca 100644 --- a/Documentation/git-replay.adoc +++ b/Documentation/git-replay.adoc @@ -62,7 +62,9 @@ The default mode can be configured via the `replay.refAction` configuration vari Range of commits to replay; see "Specifying Ranges" in linkgit:git-rev-parse[1]. In `--advance ` mode, the range should have a single tip, so that it's clear to which tip the - advanced should point. + advanced should point. Any commits in the range whose + changes are already present in the branch the commits are being + replayed onto will be dropped. include::rev-list-options.adoc[] -- cgit v1.3