Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.51.0.windows.1 cpu: x86_64 built from commit: 4d21a77b98af5cf479d8b6f863c2aa94257cd4e1 sizeof-long: 4 sizeof-size_t: 8 shell-path: D:/git-sdk-64-build-installers/usr/bin/sh feature: fsmonitor--daemon libcurl: 8.15.0 OpenSSL: OpenSSL 3.2.4 11 Feb 2025 zlib: 1.3.1 SHA-1: SHA1_DC SHA-256: SHA256_BLK default-ref-format: files default-hash: sha1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.22631.5909] 

Options set during installation

Editor Option: Notepad Custom Editor Path: Default Branch Option: Path Option: CmdTools SSH Option: OpenSSH Tortoise Option: false CURL Option: WinSSL CRLF Option: CRLFCommitAsIs Bash Terminal Option: ConHost Git Pull Behavior Option: Rebase Use Credential Manager: Enabled Performance Tweaks FSCache: Enabled Enable Symlinks: Disabled Enable FSMonitor: Disabled 

Other interesting things

Remote server is apparently case-sensitive (Unix).

Terminal/shell

cmd

Commands that trigger the issue

I am running on Windows 11. First, someone else using the same Git remote repository as me apparently deleted two branches whose names differed only by case. (e.g. origin/Bug12345_master and origin/Bug12345_Master). Then, later, I did a 'git fetch' on my local system. 

Expected behaviour

Successful 'git fetch'.
Any local copies of either/both branches would be removed.

Actual behaviour

I got an error message like this:

C:\wherever>git fetch error: could not delete references: cannot lock ref 'refs/remotes/origin/Bug12345_master': Unable to create 'C:/src/tanner_tools/main/.git/refs/remotes/origin/Bug12345_master.lock': File exists. 

Note that there was no lock file at the path that it reported.

My initial attempts to do this were from Visual Studio. I also seem to remember getting some text that said something like:

Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue. 

However, I could not reproduce this from the command line later.

The error message was unexpected and misleading. I wasted quite some time trying to figure out why the lock file which it mentioned didn't exist, and whether or not I had any additional Git processes running (I didn't).

Future attempts at 'git fetch' behaved similarly. This problem basically stopped me completely from using Git
and became a blocking issue for everything else I was doing until I eventually found a solution.

The actual problem appears to be that Git didn't notice that two branches that were being deleted from the Unix
server would map to the same branch name on my local Windows system (due to the case insensitivity of the Windows filesystem), and that therefore deleting a single local branch would have been sufficient to remove both remote branches. It instead tried to create a lock file in "the first" local branch, then delete it, and then failed to create a lock file in "the second" local branch because that folder no longer existed since it had just been deleted. Or something like that. Git should have detected that these two branch names would map to the same name on a Windows system and should have taken appropriate action to deal with that fact.

Eventually, I found the following web page, which clued me in to what was happening and provided a workaround to get my system working again:

https://stackoverflow.com/questions/79567126/git-debugging-error-could-not-delete-references-cannot-lock-ref-file-exis

Note that this web page includes additional details about similar problems occurring in other circumstances.
Please try to fix the entire set of problems, not just the narrow case I happened to encounter.

Once I receive information that this bug report has been officially filed, I will update that web page to link to it.

Also please note that this problem is likely closely related to the existing bug report #5378, and likely involves very similar (but perhaps not identical) issues.

Repository

Sorry, the repository is not public.