git checkout creating tracking branch using case-insensitive match?

[mahilleb-msft]

git checkout abcDef creates a tracking branch from origin/AbcDef (or another uniquely matching remote) using the new casing. This is probably not intended and easily yields to a new branch being published on subsequent push.

Setup

This is using Git installed via Git-2.8.2-64-bit.exe:

$ git --version
git version 2.8.2.windows.1

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

Main difference from defaults is "Commit as-is, checkout as-is". Please let me know if you think there are other options that could influence this.

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

I don't think so.

Details

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

Powershell.

• 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 abcDef
# where a unique remote exists that has a branch AbcDef (different casing)

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

error: pathspec 'abcDef' did not match any file(s) known to git.

• What actually happened instead?

A new tracking branch was created with the new casing.

[mahilleb-msft]

Hey, any comment on this? I can try to track down where this is occurring, but I'd like to understand first whether this is regarded as a bug (and whether this is the right place to report it).

Thanks!

Mark

[PhilipOakley]

The "bug" (which it isn't as far as the case sensive Linux is concerned), is buried in the various branch creation and statusing codes.

There was a report about checking out branches with the wrong case and getting confused (e.g. git branch say what branch you were on, would list your branches, and highlight none of them as current!)

Part of the issue is that the name of the branch is held separate from the path to the branch, so (especially after it has gone through the ref DWIMery) you can't tell if the file opened when creating the branch ref, has the right case.

It may be that the one option is to add a check in an appropriate bit of code that the names and the ref path do (or don't) have the same case.

The Upstream are unlikely to accept it unless it is carefully crafted so that it doesn't slow down their code, doesn't have ifdefs inside the code, and has a suitable config flag. (and tests and all the other stuff).

My notes (from dec 2015) attached Git Checkout Case sensitivity.txt

[dscho]

My 2 cents: I think that we will eventually have a case-sensitive refs backend even on Windows, in which case your command would fail (because it would not mistake origin/abcDef for origin/AbcDef).

So I would like to see a warning if the case was wrong, but still let things go forward after that, for now.

[alpersogukpinar]

I had the same issue at git version 2.11.0.windows.1, Case Steaps

1. I am in feature/testCoverage branch and I run git checkout feature/TestCoverage command
2. When I check the .git\HEAD file, it shows new branch name ref: refs/heads/featureTestCoverage
3. I change something in the local repository then commit and push to the origin.
4. I see [new branch] creation message at command prompt. When I push to the origin and check branches at the server, I see that a branch named feature/TestCoverage has been created at the server.

When I checkout the branch with the wrong case, I expect git to give an error like “.. branch not found” or checkout the already available branch by ignoring case.

I handled this issue by writing a server-side event handler at TFS Git to handle the issue. My handler subscribes to a notification called PushNotification and rejects push request if there is already a branch with the same name at the server.

[dscho]

Related ticket: https://github.com/git-for-windows/git/issues/1623