summaryrefslogtreecommitdiffstats
path: root/contrib/persistent-https
diff options
context:
space:
mode:
authorPhillip Wood <phillip.wood@dunelm.org.uk>2025-12-18 16:50:26 +0000
committerJunio C Hamano <gitster@pobox.com>2026-01-13 06:13:37 -0800
commit0ee71f4bd035db61342c2c5a25984e4545347c11 (patch)
treefcd0a547f000500708633f2dbfbbd935de8a7f6d /contrib/persistent-https
parent9e4a786c3db10205fbc8c6a0aa1f14c4ca325760 (diff)
downloadgit-0ee71f4bd035db61342c2c5a25984e4545347c11.tar.gz
git-0ee71f4bd035db61342c2c5a25984e4545347c11.zip
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 <newren@gmail.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/persistent-https')
0 files changed, 0 insertions, 0 deletions