If the same commit is made and then reverted on both <upstream> and
<branch>, and then reapplied only on <branch>, then
`git rebase <upstream> <branch>` will skip the reapplied commit.
The following script demonstrates the issue:
```
#!/bin/sh -eu
# Set up a repo for the following commands.
repo_directory="./rebase-test-repo"
rm -rf "${repo_directory}"
mkdir -p "${repo_directory}"
cd "${repo_directory}"
git init -b main
git config user.name test
git config user.email test@xxxxxxx
# Create a branch 'br' starting from a commit other than the tip of the
# 'main' branch. Switch to it.
git commit --allow-empty -m 'initial commit'
git commit --allow-empty -m 'another empty commit'
git switch --create br HEAD^
# Create a non-empty commit on 'br', then revert it.
touch a
git add a
git commit -m 'Add a'
git revert --no-edit HEAD
# Make identical commits on 'main'.
git switch main
touch a
git add a
git commit -m "Add a (on 'main')"
git revert --no-edit HEAD
# Reapply the reverted commit to 'br'.
git switch br
git revert --no-edit HEAD
# Rebase 'br' onto 'main'.
git rebase main br
git -P log --graph --all --oneline
# Sample output:
#
# * 5b4d655 (HEAD -> br, main) Revert "Add a (on 'main')"
# * 7881a38 Add a (on 'main')
# * 907f1a8 another empty commit
# * 6c094a9 initial commit
#
# What we expect to see:
# The commit 'Reapply "Add a"' should have been rebased onto 'main'.
#
# What we see:
# This commit was skipped during the rebase and has been lost.
```
Using the '--reapply-cherry-picks' option prevents this from happening,
but it also creates empty commits, so it's not a proper workaround.
[System Info]
git version:
git version 2.48.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /gnu/store/jlqbjxk51bdq5w7wlnbmwxm1j0pnllpx-bash-minimal-5.1.16/bin/sh
zlib: 1.3
compiler info: gnuc: 11.4
libc info: glibc: 2.39
$SHELL (typically, interactive shell): /gnu/store/cdwviyfnsfv7k57qrwmym0mrynjixc1i-bash-5.1.16/bin/bash
[Enabled Hooks]
not run from a git repository - no hooks to show
