On Tue, Mar 11, 2025 at 11:11 AM 45mg <45mg.writes@xxxxxxxxx> wrote:
>
> 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.
Yes, as expected and as documented. Another commit exists upstream
which introduces the same change, so it is omitted.
> 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
Note that this does not match your original description, and your
comment here, "Make identical commits on 'main'" is not (always)
correct. If there's even a little lag between when the last two
commands run and the ones before them, then the commits on 'br' and
the commits on 'main' are not the same.
> # Reapply the reverted commit to 'br'.
> git switch br
> git revert --no-edit HEAD
>
> # Rebase 'br' onto 'main'.
> git rebase main br
I would have expected
git rebase --onto main br~1 br
due to the non-identical commits issue I mentioned above, though
without --reapply-cherry-picks it doesn't really matter. With
--reapply-cherry-picks, though, it matters because I would have
expected you wanted 5 commits rather than 7 (empty initial commit,
another empty commit, Add a on main, revert add a on main, Add a,
revert that, Reapply add a).
> 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.
> ```
Yes, it's behaving as documented.
> Using the '--reapply-cherry-picks' option prevents this from happening,
> but it also creates empty commits, so it's not a proper workaround.
It'll only create an empty commit if (a) the commit being
cherry-picked is empty, or (b) the application of the changes from the
commit result in no-change.
In this example you provided, no empty commit would be created
(whether or not you used your original rebase command or the
modification I expected).
So, it looks like precisely the appropriate workaround if you really
want to reapply these commits. Why do you think it's not the right
workaround?
