Git for Win doesn't correctly handle branch names that differ only by case

[robrich]

Note: This feels like a problem with git fetch and/or git remote prune ... or with storing branches as folders. Feel free to 301 me to a better repository for this issue.

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

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

64-bit Git version 2.19.1

$ git --version --build-options

git version 2.19.1.windows.1
cpu: x86_64
built from commit: 11a3092e18f2201acd53e45aaa006f1601b6c02a
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17134.345]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCode
Custom Editor Path:
Path Option: CmdTools
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Rebase: Disabled
Enable Builtin Stash: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Happens on other environments, OS's, Windows versions, and git versions.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

// from machine 1
git clone https://some-url
git checkout -b BRANCH/UPPERCASE
git push origin BRANCH/UPPERCASE

// from machine 2
git clone https://some-url
git checkout -b branch/lowercase
git push origin branch/lowercase

// from machine 1
git fetch
// creates `origin/BRANCH/lowercase`
git remote prune origin
// removes `origin/BRANCH/lowercase`
git fetch
// creates `origin/BRANCH/lowercase`

// from machine 2
git fetch
// creates `origin/branch/UPPERCASE`
git remote prune origin
// removes `origin/branch/UPPERCASE`
git fetch
// creates `origin/branch/UPPERCASE`

• What did you expect to occur after running these commands?

Git could keep branch/lowercase and BRANCH/UPPERCASE separate

• What actually happened instead?

branch/lowercase became BRANCH/lowercase and BRANCH/UPPERCASE became branch/UPPERCASE because the branch folder already existed on machine 1, and the BRANCH folder already existed on machine 2, and Windows is a case-insensitive file system.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

I've reproed this concern with a private VSTS repo, but any Git hosting should do. I have no URL that demonstrates this issue.

Note: Git also can't have branch names with non-windows characters (<, >, :, ", /, \, |, ?, *) for the same reason, see also #1656 and https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file

[PhilipOakley]

This is a known issue of Git being a Linux tool, ported to Windows. It becomes worse if one is also collaborating with *nix users who don't see the problems...

If you have a look through the 'closed' issues there are a number of discussions about case sensitivity issues. At the moment there are no effective proposals that would fix the issues.

If you are able to identify a possible solution to some aspect of the issue then that would help.

[PhilipOakley]

The wiki page on these general issues is:

https://github.com/git-for-windows/git/wiki/File-names,-Branch-names,-Path-quotation,-Executable-bit-and-file-modes,-core.FileMode

[robrich]

I'd like an option in git to say "treat all branch names as lower-case in spite of what I typed" so that creating FEATURE/UPPERCASE will actually create the feature/uppercase branch. I grant this is a bit heavy-handed, but it would proactively solve the day 2 problems I see.

[PhilipOakley]

The problem comes when one is collaborating with others that are on a case sensitive system and then use CamelCase (or is that camelCase). If they created a Source branch and we lower case command line mentions of it to source then we are (as far as Git internal are concerned) are on a different branch.

It gets worse for UTF internationalisation and localisation (apparently the worst is the Turkish 'i').

That said, Pull Requests (PR) are always welcome, even if it's still in draft. The PR could even be just better signage in the upstream Git (which populates git-scm) and git-for-windows documentation!

[robrich]

Good call. This needs to be larger than just windows-only set in an unsync'd folder. Perhaps a better proposal: a mechanism for validating branch names throughout a repository -- a pre-"branch" hook of sorts. So a tam can say "here's the regex for our branch names, and all branches must pass this regex to get created."

[PhilipOakley]

Good call. This needs to be larger than just windows-only

Correct, one area that would need refactoring is the branch-name / pathname distinction that exists in the code paths. Often the branch-name is a distinct variable, different from the pathname (in the Git code), so it is not always possible to check, in the current code, if the case is different.

Plus there is the need to interrogate the OS to determine its view of the file name (which can be slow if many paths need checking).

Further, conceptually, branch names are just long strings. They are not truly paths, rather the fact that git uses them as if they are paths is just an implementation detail that POSIX handily supports (but the windows FS doesn't). It is a guddle!

[alegrigoriev]

Possible solution:
If the refname != lowercase(refname), then it should go straight to packed-refs (or, for lookup, checked against packed-refs). This will make working with those refs a bit slower, or not.

[geekley]

Not sure if this is the same issue, but this happened to me:
I added and commited files in:

Example\\path.ext
Example\\path\\file1.ext
...

Then I renamed the folder to Path, but git didn't recognize the "deleted part" of the renaming.
So when I run git status, it only shows the untracked files in the new path, but not the old path deleted.

Example\\Path.ext
Example\\Path\\file1.ext
...

This makes me unable to mark the files as renamed, I can only mark them as added.
(btw, my repo has core.ignorecase = false in git config)
(I should also mention that GitKraken handles this correctly)

---

Windows is a case-insensitive file system

I think it's worth mentioning explicitly that what can be case-insensitive is not exactly Windows, but NTFS, FAT, etc. So these case-sensitivity issues may be relevant for git for unix as well, since unix can mount these file systems (as case-insensitive) as well.

[tboegi]

@geekley : it is not the same issue.
In short:
git mv path Path

will tell Git about the rename.
The long version is all in the documentation:
https://git-scm.com/docs/git-config

[geekley]

git mv path Path didn't work, git tried to rename it to Path/path for some reason.
I had to do git mv path othername and then git mv othername Path, then it worked.
Thanks. I might open a separate issue ...eventually, if I have time.

[tboegi]

Thanks for reporting - I wasn't aware that the mv does not work for directories.
And you are the first one to detect this problem..

Feel free to open a new issue, or (may be better) report it to upstream Git.
As it affects even MacOS users (or Linux on VFAT)

[dscho]

report it to upstream Git.

Indeed, this would be the best idea: [email protected]

[geekley]

Well, I'm lacking the time to test and write a proper bug report at the moment... I'm busy on a project, and it might take a while for me to be able to do it.
Would any of you guys mind reporting it for me instead, if it's not too much trouble?

[dscho]

Well, I'm lacking the time to test and write a proper bug report at the moment...

No worries. If it is not that pressing a problem for you, it can safely wait until you have the time. No need to lean on other people for something you obviously do not need all that badly.

[dscho]

Closing this as stale.