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

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

[Marco Stephan]

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

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

[Junio C Hamano]

Marco Stephan <marc.stephan96@hotmail.de> writes:

> 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 wonder if

    $ git update-index --refresh

is all it takes.  The symptom, i.e. Git declares that an otherwise
unmodifed path is not uptodate, is not limited to "revert" or
aborting it, but is a common thing a newbie sees after copyihg a
working tree to elsewhere, and "refresh the index" is an often given
recovery procedure for such a situation.

I'll not comment if this is a bug or not, and let others argue.

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

[Kristoffer Haugsbakk]

On Sun, Nov 3, 2024, at 03:34, Junio C Hamano wrote:
> Marco Stephan <marc.stephan96@hotmail.de> writes:
>
>> 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 wonder if
>
>     $ git update-index --refresh
>
> is all it takes.


This is correct.  This successful test can be added to
t3501-revert-cherry-pick.sh:

```
test_expect_success 'cp -r repo in the middle of a revert' '
	test_when_finished rm -r new-repo &&
	test_when_finished rm -r copy-repo &&
	test_create_repo new-repo &&
	(
		cd new-repo &&
		echo nul >test.txt &&
		git add test.txt &&
		git commit -m "Initial commit" &&
		echo test >test.txt &&
		git add test.txt &&
		git commit -m "Changes" &&
		git revert HEAD --no-commit
	) &&
	cp -r new-repo copy-repo &&
	(
		cd copy-repo &&
		# Needed in order to avoid
		#     error: Entry test.txt not uptodate. Cannot merge.
		git update-index --refresh &&
		git revert --abort
	)
'
```

-- 
Kristoffer Haugsbakk

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

[Kristoffer Haugsbakk]

On Sun, Nov 3, 2024, at 16:04, Kristoffer Haugsbakk wrote:
> On Sun, Nov 3, 2024, at 03:34, Junio C Hamano wrote:
>> Marco Stephan <marc.stephan96@hotmail.de> writes:
>>
>>> 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 wonder if
>>
>>     $ git update-index --refresh
>>
>> is all it takes.
>
>
> This is correct.  This successful test can be added to
> t3501-revert-cherry-pick.sh:

(Meaning one can add it there if one wants to see for themselves)

-- 
Kristoffer Haugsbakk

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

[Kristoffer Haugsbakk]

On Sun, Nov 3, 2024, at 02:25, Marco Stephan wrote:
> 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.

Okay, I missed that `git update-index --really-refresh` previously.

I’m not a technical expert but is there a use-case here?  Or did you
find this by accident while doing something else?

-- 
Kristoffer Haugsbakk

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

[Marco Stephan]

On Sun, Nov 3, 2024, at 16:13, Kristoffer Haugsbakk wrote:
> Okay, I missed that `git update-index --really-refresh` previously.
> 
> I’m not a technical expert but is there a use-case here?  Or did you
> find this by accident while doing something else?

I stumbled upon this behavior while working on some Git scripts. For these, I've prepared template repositories which I then copy and run the scripts on. This specific scenario in which I want to abort a revert in progress is, so far, the only scenario where this copying causes problems. All other Git commands I've used seem to simply ignore it or "refresh the index" on their own. For example, "git cherry-pick --abort" does not run into this problems for me.

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

[Phillip Wood]

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

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

[Marco Stephan]

On Sun, Nov 4, 2024, at 10:55, Phillip Wood wrote:
> "git revert --abort" is a wrapper around "git reset --merge" so I wonder
> if we should change "git reset --merge" to refresh the index.

In my novice opinion I agree. If "git revert --abort" is just a wrapper for "git reset --merge" then I think "git reset --merge" should itself refresh the index. Other commands (e.g. "git cherry-pick --abort") seem to perform a refresh as well.