FetchCommand fails if 2 branches have the same name but differ only in case

[sokai116]

Version

6.10.0.202406032230-r

Operating System

Windows

Bug description

FetchCommand fails when fetching all branches in Windows OS if any 2 branches have the same name but differ only in case.
This is because it can't create a new file to lock e.g. "feature/branch-A" after another "feature/branch-a" has already been made, so lockLooseRefs(pending); in PackedBatchRefUpdate will return null, and then the fetch silently fails.

Special handling may be needed for Windows, as locking a lower(or upper) case branch is guaranteed to lock all branches differently in case, no need to lock again for any other "synonyms" branches.

Actual behavior

The fetch silently fails, and the FetchCommand shows success but nothing is updated. Try to fetch again will always be the same until one of those branches is deleted in remote.

Expected behavior

The repository remote index is updated.

Relevant log output

No response

Other information

No response

[MarkEWaite]

Microsoft recommends to avoid this situation by not using refs that differ only in case.

[msohn]

PackedBatchRefUpdate checks for name conflicts [1] but doesn't yet consider to compare refs case-insensitive if the filesystem is case-insensitive [2]. The packed-refs format could store multiple refs which only differ in case, though, if the filesystem is case-insensitive, I guess it's better to raise an error early in such cases since the case-insensitive filesystem couldn't handle multiple loose refs which are only different in case.

[1] https://github.com/eclipse-jgit/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackedBatchRefUpdate.java#L137
[2] https://github.com/eclipse-jgit/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackedBatchRefUpdate.java#L213