Re: git rebase skips reapplied commits

From: Elijah Newren <newren@gmail.com>
Date: Mar 11, 2025, 18:55 UTC
Message-ID: <CABPp-BH0xziowZx4S2aKJL5wjPHbJQ8wNstPUSLaw0FNdDu-fg@mail.gmail.com>
In-Reply-To: <87jz8v8mlj.fsf@gmail.com>

On Tue, Mar 11, 2025 at 11:11 AM 45mg <45mg.writes@gmail.com> 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.

Show 32 quoted lines

> 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@no.mail
>
> # 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.

Show 6 quoted lines

> # 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).

Show 14 quoted lines

> 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?