From: Elijah Newren Date: Tue, 16 Dec 2025 16:36:16 GMT Subject: Re: [PATCH v3] replay: drop commits that become empty Message-ID: In-Reply-To: <73ba74b8a2e7aaa625e6f0689a9f900ceebaaa03.1765894781.git.phillip.wood@dunelm.org.uk> On Tue, Dec 16, 2025 at 6:19 AM Phillip Wood wrote: > > From: Phillip Wood > > 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 > --- > Changes since v2: > > - added a couple of commas to the commit message as suggested by Junio - also changes "can been seen" to "can be seen" I'm also curious if you are keeping the "--only" in the testcase intentionally, or overlooked that part of Junio's feedback. Anyway, this round looks good to me.