Git revert cannot be aborted if the repository directory has been copied

Hello,

I have encountered the following bug:
If you copy a Git repository directory to another path while there is a revert in progress for the Git repository, "git revert --abort" does not work anymore for the copied repository. Instead, it will report an error of the following format:
      error: Entry '...' not uptodate. Cannot merge.
      fatal: Could not reset index file to revision '...'.

I can reproduce the bug consistently with the latest version of Git that is available for Windows (git version 2.47.0.windows.2) by performing the following steps (all command line except step 12):
1. mkdir test_repo
2. cd test_repo
3. git init
4. type nul > test.txt
5. git add .
6. git commit -m "Initial commit"
7. echo test > test.txt
8. git add .
9. git commit -m "Changes"
10. git revert HEAD --no-commit
11. cd ..
12. Manually copy test_repo to a new directory test_repo_copy using the file explorer (using e.g. "robocopy test_repo test_repo_copy /E" does not corrupt the repository)
13. cd test_repo_copy
14. git revert --abort
This consistently produces the error "error: Entry 'test.txt' not uptodate. Cannot merge.". I would expect step 14 to work regardless of how the repository directory itself has been created. Running "git status" or "git update --really-refresh" fixes the seemingly corrupt data and the revert in progress can be aborted.

I have not verified if the bug is present on other operation systems, too.

With best regards Marco Stephan