-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"error: could not delete references" due to non-existent lock file #5378
Comments
nb. I've since solved this issue by removing the offending branch from |
This should be relatively easy to turn into an actual reproducer, i.e. a script that sets up a local repository, clones it, then makes some changes in the first one, then fetches into the cloned repository. |
I unfortunately don't have the exact sequence of events that got me into this situation. I tried to reproduce it, but didn't get this exact error. I got a different error though which is presumably related to this one: On Windows, you can create the “upstream” test repository in WSL2 so you have a case-sensitive file system. Create the "upstream repository" and two branches: mkdir testrepo-upstream
cd testrepo-upstream
git init .
git commit --allow-empty -m "test 1"
git branch test-branch
git commit --allow-empty -m "test 2"
git branch Test-Branch Create the victim repository on an NTFS volume, and fetch: mkdir testrepo-victim
pushd testrepo-victim
git init .
git remote add r1 //wsl.localhost/path-to/testrepo-upstream
git fetch r1 Now update the branches: # On testrepo-upstream:
git commit --allow-empty -m "test 3"
git branch -f test-branch
git commit --allow-empty -m "test 4"
git branch -f Test-Branch And fetch on the victim: # On testrepo-victim:
git fetch r1 This prints an error:
This error was however recoverable by fetching again after the upstream branches were removed. This repo also does not have a |
Git is unable to remove a stale remote reference. (this is a branch that was deleted on the remote GIT repository).
(branch name and paths shortened, but the paths involved are well within normal path length limits on Windows)
However this lock file does not exist.
Tracing git.exe in
procmon
shows that the process is creating the file, then noticing its existence, and then removing the file.Installation info:
The text was updated successfully, but these errors were encountered: