From: Phillip Wood Date: Mon, 04 Nov 2024 09:55:23 GMT Subject: Re: Git revert cannot be aborted if the repository directory has been copied Message-ID: In-Reply-To: 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