On 03/11/2024 01:25, Marco Stephan wrote:
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 '...'.
"git revert --abort" is a wrapper around "git reset --merge" so I wonder if we should change "git reset --merge" to refresh the index.
Best Wishes Phillip
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
