Re: [regression][bisected] git-subtree remote desynchronization

> What did you do before the bug happened? (Steps to reproduce your issue)
>
> I have upgraded my local git installation from v2.53.0-rc0 to 2.53.0-rc1 and
> noticed that I can not use my local packaging repository monorepo (via
> aurpublish) anymore.
>
> The steps for reproduction are the following:
>
> 1. Update to the 2.53.0-rc1 git release candidate
> 2. Clone my monorepo for packages in the Arch User Repository:
>    ```
>    git clone https://github.com/christian-heusel/aur.git && cd aur
>    ```
> 3. Push changes to one of the contained subtree remotes (this would normally be
>    done via `aurpublish google-chrome`):
>    ```
>    git subtree push -P "google-chrome" ssh://aur.archlinux.org/google-chrome.git master
>    ```

> What did you expect to happen? (Expected behavior)
>
> There are no changes expected since the repositories are synced after each
> modification to publish the updates to the AUR:
> ```
> $ git subtree push -P "google-chrome" ssh://aur.archlinux.org/google-chrome.git master
> git push using:  ssh://aur.archlinux.org/google-chrome.git master
> Everything up-to-date
> ```
>
> What happened instead? (Actual behavior)
>
> ```
> $ git subtree push -P "google-chrome" ssh://aur.archlinux.org/google-chrome.git master
> git push using:  ssh://aur.archlinux.org/google-chrome.git master
> To ssh://aur.archlinux.org/google-chrome.git
>  ! [rejected]          70b3d81e370936e96f98d0aba357490b75ade7a9 -> master (non-fast-forward)
> error: failed to push some refs to 'ssh://aur.archlinux.org/google-chrome.git'
> hint: Updates were rejected because a pushed branch tip is behind its remote
> hint: counterpart. If you want to integrate the remote changes, use 'git pull'
> hint: before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> ```
>
> What's different between what you expected and what actually happened?
>
> I would expect the `git subtree push` command to stay functionally equivalent
> and the change mentioned above regresses my workflow. This tool and setup is
> also not really special as a lot of users within the Arch Linux packaging
> ecosystem are relying on this workflow.
>
> Anything else you want to add:
>
> I have bisected the issue to the following commit:
>
>     28a7e27cff ("contrib/subtree: detect rewritten subtree commits")
>
> This is my bisection log:
> ```
> $ git bisect start
> # status: waiting for both good and bad commits
> # good: [7264e61d87e58b9d0f5e6424c47c11e9657dfb75] Git 2.53-rc0
> git bisect good 7264e61d87e58b9d0f5e6424c47c11e9657dfb75
> # status: waiting for bad commit, 1 good commit known
> # bad: [83a69f19359e6d9bc980563caca38b2b5729808c] Git 2.53-rc1
> git bisect bad 83a69f19359e6d9bc980563caca38b2b5729808c
> # bad: [0a5dcc1259fa0c8f5c21352c90b3cd3d43273345] Merge branch 'tb/macos-iconv-workarounds'
> git bisect bad 0a5dcc1259fa0c8f5c21352c90b3cd3d43273345
> # good: [ffae4da0128e035acd1887654c98b4f02785adec] Merge branch 'kh/doc-patch-id'
> git bisect good ffae4da0128e035acd1887654c98b4f02785adec
> # good: [6edbb7b1d0b50c70e2af0b5f68b7db0984b10be2] Merge branch 'en/fsck-snapshot-ref-state'
> git bisect good 6edbb7b1d0b50c70e2af0b5f68b7db0984b10be2
> # good: [9813aace1e52765e01e688672cdcdcbe25336ec7] Merge branch 'je/doc-reset'
> git bisect good 9813aace1e52765e01e688672cdcdcbe25336ec7
> # good: [d28124151851e42a3bb92963f5b747ad843f33e0] utf8.c: enable workaround for iconv under macOS 14/15
> git bisect good d28124151851e42a3bb92963f5b747ad843f33e0
> # bad: [79e3055baba32e2952e6e8994cdcd4fc145ba7f0] Merge branch 'cs/rebased-subtree-split'
> git bisect bad 79e3055baba32e2952e6e8994cdcd4fc145ba7f0
> # bad: [28a7e27cff717e5ef91f7445e6a418068608082d] contrib/subtree: detect rewritten subtree commits
> git bisect bad 28a7e27cff717e5ef91f7445e6a418068608082d
> # first bad commit: [28a7e27cff717e5ef91f7445e6a418068608082d] contrib/subtree: detect rewritten subtree commits
> ```