2.29.0.rc0.windows.1: Duplicate commit id error message when fetching

[Thomas Braun <thomas.braun@virtuell-zuhause.de>]

Hi,

I'm using

$ git --version
git version 2.29.0.rc0.windows.1

Since I upgraded to that version (thanks to dscho for providing these so
early) I'm seeing occasionally

$ git fetch origin +refs/head/abcd:refs/remotes/origin/abcd
fatal: unexpected duplicate commit id
31a13139875bc5f49ddcbd42b4b4d3dc18c16576

The local branch abcd is at

$ git rev-parse HEAD
b6ae1ee2adcb75aee09c4a8d72bfd66f32f6fae1

while its remote tracking branch is at

$ git rev-parse @{u}
31a13139875bc5f49ddcbd42b4b4d3dc18c16576

I have pull.rebase=true set but I think this does not matter for fetch.
I do have protocol V2 enabled.

A full trace is

$ GIT_TRACE=1 git fetch origin +refs/heads/abcd:refs/remotes/origin/abcd
22:23:42.016859 exec-cmd.c:237          trace: resolved executable dir:
C:/Program Files/Git/mingw64/bin
22:23:42.018858 git.c:444               trace: built-in: git fetch
origin +refs/heads/abcd:refs/remotes/origin/abcd
22:23:42.020858 run-command.c:663       trace: run_command: unset
GIT_PREFIX; GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL
git@github.com 'git-upload-pack '\''XXX/YYY.git'\'''
22:23:43.284643 run-command.c:663       trace: run_command: git rev-list
--objects --stdin --not --all --quiet --alternate-refs
22:23:43.344644 run-command.c:663       trace: run_command: git rev-list
--objects --stdin --not --all --quiet --alternate-refs
22:23:43.358613 exec-cmd.c:237          trace: resolved executable dir:
C:/Program Files/Git/mingw64/libexec/git-core
22:23:43.360614 git.c:444               trace: built-in: git rev-list
--objects --stdin --not --all --quiet --alternate-refs
22:23:43.492616 run-command.c:1617      run_processes_parallel:
preparing to run up to 1 tasks
22:23:43.492616 run-command.c:1649      run_processes_parallel: done
fatal: unexpected duplicate commit id
31a13139875bc5f49ddcbd42b4b4d3dc18c16576

The repo is public, so if it helps I can provide a link.

Anything I'm doing wrong here?

Thanks,
Thomas