folder name should be case sensitive when switch branches

[chucklu]

Setup

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

$ git --version --build-options

git version 2.14.2.windows.3
built from commit: 924c19fc000d3759486b68bd73bc592fa02e367c
sizeof-long: 4
machine: x86_64

• 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.10586]

• 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

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

Details

• Description
  I have two branches, branch v1.6 and branch master.
  Here is a folder at the same location in both branches.
  On branch v1.6 ,the folder name is Test, the first character T is capital.
  On branch master, the folder name is test, the first character t is in lower case.
  I am on branch v1.6 now,and try to switch to master.

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

• 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.

git checkout master

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

checkout the source code with folder test

• What actually happened instead?

the source code was checked out in Test folder,should rename folder name from Test to test.

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

not happened in specified repository, but you can check this repository

[dscho]

Indeed, this is a problem with Git's idea of treating case-insensitive file systems.

Sadly, I lack the time to drive this fix. @chucklu do you have time?

[chucklu]

@dscho I am not familiar with language c, I try to find a file named as git-checkout.c, but no lucky.
I have no idea about this project's structure.

[PhilipOakley]

@chucklu What actually happens for you in this case?

Who does this affect - Windows users, or Linux users. e.g. what part of which program detects that this 'change' appears to have happened? Windows shouldn't care, but clearly something is.

[chucklu]

@PhilipOakley I am using TortoiseGit to check the git status by icon.
The folder name under branch v1.6 is Test, the folder name under branch master is test.
Since the real folder name is test, but you keep it as Test.
When I switch the branch from v1.6 to master, TortoiseGit can not recognize the Test folder on branch master. When I rename it from Test to test manually, then TortoiseGit can mark the folder with icon.

[PhilipOakley]

A rename detection improvement series came up on the usptream Git list today https://public-inbox.org/git/3076EE0E678D43B286F86E622CB9F06E@PhilipOakley/ and https://public-inbox.org/git/CABPp-BH4LLzeJjE5cvwWQJ8xTj3m9oC-41Tu8BM8c7R0gQTjWw@mail.gmail.com/

It's likely to be a bit of a can of worms to provide sensible options as to whether the user wants the in-place rename to happen, or not, or if status should notice, and then what gets stored in the next commit. Once such an un-noticed capitalisation change has happened in the repo it is there to see forever. Canonically it IS a change, so reasonably git checkout should rename the directory.

[d4e666]

I have the same issue. I try to merge 2 branches and 1 contains a rename from UserCurves to Usercurves. I even renamed the folder and files in BOTH branches to UserCurves AND STILL THE MERGE REPORTS DUPLICATES. How hard can it be to make file/folder compare case IN sensitive and leave the case sesitive option only for FILE CONTENTS. I don't care that linux is case sensitive, I USE WINDOWS!!!!!!!!!!!!! Every developer that claims "case sensitive filesystems" are better should go back to kinder garten where he belongs. If you develop a system for a case insensitive OS, then make it work!!!!!!!!!!!!!!!!!!!!!!! you know the limitations of an OS, stick to it instead of playing the LAZY developer

[d4e666]

it would help if I could edit the git repo directly and just remove the duplicate file or do something with it without having to download the file. This way I would be able to remove the file without having to download it and just remove the flaws directly.

[PhilipOakley]

@d4e666, as a dev yourself, you should be able to help out here. As you will no doubt know, Git was designed explicitly for linux and to be a flexible, open source, distributed version storage system.

So the GfW port is a special case and there are few devs supporting it, so every little contribution helps, eespecially for issues that are a personal itch. It is easy to begin to contribute - just pop over to https://git-for-windows.github.io/#contribute and download the SDK, it will download and compile everything.

You can support @chucklu in determining where the code asks to select/create the directory for checkout or merge and the Windows file system reports it has found the alternate cased directory, but without mentioning that there is a case change. Knowling where that point is in the code would be very helpful.

[dscho]

This is probably a bit more involved a project, as there are a couple of parts to it.

How does git checkout access the refs?

First of all, git checkout handles the branch argument here: https://github.com/git/git/blob/1eaabe34fc6f486367a176207420378f587d3b48/builtin/checkout.c#L1002-L1009

In other words, it simply uses the read_ref() function. This function is declared in refs.h and defined in refs.c, but eventually it is refs_resolve_ref_unsafe() which uses refs_read_raw_ref() to hand off to the refs backends.

Step 1: add a flag

The first task is to change the signature of refs_read_raw_ref() (and consequently, of read_raw_ref_fn) to include the flags that refs_resolve_ref_unsafe() still receives, and then add a flag to perform case-insensitive matching (similar to RESOLVE_REF_ALLOW_BAD_NAME).

Step 2: teach the refs backends

After that, the two backends need to learn about that flag: packed_read_raw_ref() and files_read_raw_ref().

Step 2a: teach the packed refs backend

For the former, it is probably enough to add handling for a config setting (refs.caseInsensitive? or maybe reuse core.ignoreCase?) to sort_snapshot() and make cmp_record_to_refname() a function pointer that gets adjusted after reading the config setting (this function is also used e.g. by find_reference_location()).

Step 2b: teach the packed refs backend

For the latter, it gets hairier: either the files_ref_path() function should be enhanced so that it can perform case-insensitive lookups even on case-sensitive filesystems, or it should very clearly error out when we know that we are on a case-sensitive filesystem.

Consideration: tightly couple the filesystem's case-sensitivity to the refs' case-sensitivity

Or we declare defeat and really declare that ref names are case sensitive only on case sensitive filesystems. Which is a bit too much for my liking, as future refs backends (and indeed, the packed refs backend) should not inherit any such limitation from the current filesystem.

But it would be easier to declare defeat, in which case Step 1 above would not even be necessary.

How to develop this?

All of this can be developed relatively easily in Git for Windows' SDK, or using Visual Studio.

Up For Grabs!

And with this pretty detailed description, I declare this ticket Up For Grabs. Y'all benefit from Git being Open Source, y'all can contribute back.

[chucklu]

@dscho @PhilipOakley
Today, I find the case sensitive affects not only git checkout,but also git branch -m and git fetch --all --prune.

1.git branch -m
when rename a branch from Abc to abc ,git bash will failed with “branch name already exists”

2.The is a branch Abc on git server, which map to origin in local
2.1 git push origin -d Abc
2.1 git push origin abc:abc
2.2 git fetch --all --prune
The --prune command only delete origin/Abc in local repository, did not create a origin/abc at the same time.
I have to run git fetch --all --prune again to fetch it.