Case-insensitive filesystem conflicts prevent repository cloning on Windows using LibGit2Sharp

[rachit-ranjan16]

GitHub Issue for Azure/azure-rest-api-specs

Title

🐛 Case-insensitive filesystem conflicts prevent repository cloning on Windows using LibGit2Sharp

Labels

• bug
• windows
• infrastructure

---

Description

The Azure/azure-rest-api-specs repository contains branch names that differ only by case, causing fatal errors when cloning on Windows (case-insensitive filesystem) using LibGit2Sharp. This affects automated tooling and CI/CD pipelines that rely on LibGit2Sharp for Git operations.

Impact

• 100% clone failure rate on Windows with LibGit2Sharp since October 21, 2025
• 4,512+ consecutive failures over 31+ days in production systems
• Affects: Azure Resource Graph, ARM Resource Providers, Azure Portal integrations, and other Microsoft services
• Blocks automated API version updates for Azure resource providers

Error Message

LibGit2SharpException: cannot lock ref 'refs/remotes/origin/azure', there are refs beneath that folder

Root Cause

On Windows (case-insensitive NTFS), LibGit2Sharp creates individual ref files in .git/refs/remotes/origin/. When branch names differ only by case OR when a branch name conflicts with a directory structure created by another branch, the clone operation fails because Windows cannot create both a file and directory with the same name (case-insensitive).

Reproduction

Environment

• OS: Windows 10/11 (case-insensitive filesystem)
• Tool: LibGit2Sharp 0.27.0 or 0.31.0
• Repository: https://github.com/Azure/azure-rest-api-specs.git

Steps to Reproduce

1. Create a .NET console app with LibGit2Sharp reference
2. Attempt to clone: Repository.Clone("https://github.com/Azure/azure-rest-api-specs.git", "test-clone")
3. Observe failure with error: "cannot lock ref 'refs/remotes/origin/azure', there are refs beneath that folder"

Test Results

All three clone attempts with different configurations fail on Windows:

• ✗ Default clone options
• ✗ With TagFetchMode.None
• ✗ With shortest possible path

Note: Git CLI (git clone) works fine because it uses packed-refs instead of individual ref files.

Conflicting Branches

🔴 CRITICAL #1: azure vs Azure/MUAChangesLoc

Branches:

• azure (lowercase) → would create FILE: .git/refs/remotes/origin/azure
• Azure/MUAChangesLoc (uppercase with slash) → creates DIRECTORY: .git/refs/remotes/origin/Azure/

Windows behavior: Cannot create both a file named "azure" and a directory named "Azure/" (case-insensitive collision)

Branch details:

• Azure/MUAChangesLoc - Last commit: April 2, 2024 by Ankur Singh
• Commit SHA: dcc3b8ce3a5e96f43f440db5ac7e0098a0ea529a
• Commit message: "Fixed intendation"

---

🟡 CONFLICT #2: KeyVault casing inconsistency

Branches:

• dev-keyvault-Microsoft.KeyVault-2022-02-01-preview (capital V in "KeyVault")
• dev-keyvault-Microsoft.Keyvault-2022-02-01-preview (lowercase v in "Keyvault")

Impact: Creates filename collision on case-insensitive filesystems

---

🟡 CONFLICT #3: MUAChangesLoc case variations

Branches:

• Azure/MUAChangesLoc (lowercase 'c')
• MUAChangesLOc (uppercase 'O', lowercase 'c')
• MUAChangesLoc (lowercase 'oc')

Impact: Multiple case variations create confusion and potential conflicts

---

Proposed Solution

Option 1: Delete Obsolete Branches (Recommended)

Delete the branches that appear to be stale or have typos:

# PRIMARY FIX - Resolves the critical blocking issue
git push origin --delete Azure/MUAChangesLoc

# ADDITIONAL CLEANUP
git push origin --delete dev-keyvault-Microsoft.Keyvault-2022-02-01-preview  # Keep capital V version
git push origin --delete MUAChangesLOc  # Has typo in 'LOc'

Backup information (for rollback if needed):

• Azure/MUAChangesLoc SHA: dcc3b8ce3a5e96f43f440db5ac7e0098a0ea529a

Option 2: Rename Branches

If these branches are still active:

git branch -m Azure/MUAChangesLoc Azure/MUA-Changes-Loc
git branch -m dev-keyvault-Microsoft.Keyvault-2022-02-01-preview \
             dev-keyvault-Microsoft.KeyVault-2022-02-01-preview-v2

Option 3: Implement Branch Naming Policy

Prevent future conflicts by enforcing:

• Branch names must not differ only by case
• Avoid directory separators (/) that conflict with existing branch names
• Standardize casing for product names (e.g., always "KeyVault", never "Keyvault")

---

Verification

After branch deletion/rename, verify Windows compatibility:

# Should succeed on Windows without errors
git clone https://github.com/Azure/azure-rest-api-specs.git test-verify

---

Additional Context

Why Git CLI works but LibGit2Sharp fails

• Git CLI: Uses packed-refs file (single file containing all refs)
• LibGit2Sharp: Creates individual files in .git/refs/remotes/origin/ hierarchy
• Result: LibGit2Sharp is more susceptible to case-insensitive filesystem issues

Business Impact

This issue is blocking critical Azure infrastructure services:

• Automated API version updates for Azure Resource Providers
• Azure Portal resource graph queries
• ARM template validation pipelines
• LAVA Store synchronization

Supporting Files

Full analysis and test results available at:

• Case conflict analysis: [Link to report]
• LibGit2Sharp test application: [Link to test code]
• Backup of branch metadata: [Link to JSON backup]

---

Request

Please delete or rename the conflicting branches listed above (particularly Azure/MUAChangesLoc which is causing the critical blocking issue). This is preventing automated tooling from functioning on Windows platforms.

Thank you for your prompt attention to this matter.

---

Environment Details:

• LibGit2Sharp versions tested: 0.27.0, 0.31.0
• Windows version: Windows 10/11
• Filesystem: NTFS (case-insensitive)
• First occurrence: October 21, 2025
• Severity: Critical (blocks automated workflows)

[rachit-ranjan16]

Mitigated by removing the branch names in the description

[mikeharder]

I renamed azure to skapur12/azure. The name azure was too generic anyway.

But since GitHub allows branches to differ in case, and this repo allows users to push arbitrary branches, I don't think there's any feasible way to prevent this long-term. We can rename branches as needed, but a user can always create <username>/foo/bar and <username>/Foo/baz, and we don't want to be responsible for renaming one.

The better fix would be to update your client to use git.exe (which should support these branches, especially if you don't need to check them out).

Or, if you only need to fetch a small portion of the repo, you could use the GitHub REST APIs instead of a full clone. Maybe using an API from Octokit, like this?

https://github.com/octokit/octokit.net/blob/7fa5b0fe4a18c9b981b21290c3ca9320b2d6415b/Octokit/Clients/IRepositoryContentsClient.cs#L26