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

[Phillip Wood <phillip.wood123@gmail.com>]

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