We have been using on premise Team Foundation Server v. 15.117.27414.0.

Everything has been working fine, except on the project's web portal, on the Code page (code explorer), all of the files that are in the git repo are not appearing. For instance, we have an MVC project with a Models folder, and there are 11 classes, but only 7 of them appear in the webpage. There are other issues with the way the project is displayed. For instance, there are two project folders with the same name (with one character the case doesn't match), with similar contents, when really there should be one.

sidebar shows two folders with same name - yet not all the files!

All of this is just confusing. Otherwise, things are working properly. We can clone the project or download it as a zip and all the files are there. It is just confusing the way it's being displayed under the Code tab in the TFS portal.

  • Since this question is about software development tools, it likely belongs more on Stack Overflow. – Edward Thomson Feb 1 '19 at 22:45

Git is a case sensitive version control system. Thus, it allows you to commit files and folders that differ only in case. This is perfectly legal and something that Azure DevOps and Team Foundation Server (and, really, every Git hosting provider) have to allow and support.

You can see this by running git ls-tree HEAD in your repository. It will show files in both the case variations.

One of two things has happened:

  • Somebody has cloned your repository on a case-sensitive filesystem (like Linux) and created a directory that differs only in case, added files to it and committed them. This is reasonably unlikely.
  • Much more likely is that somebody has cloned their repository onto a case-insensitive filesystem (like Windows) and disabled core.ignorecase. core.ignorecase instructs Git that you are on a case-insensitive filesystem and that if you run git add FOO/file.txt when there's a directory named foo already in the repository, that you actually want to use the existing directory.

core.ignorecase is not a setting that should be changed. It is not an option. It is a cached value. Git discovers your filesystem capabilities when the repository is created (case sensitivity, Unicode capabilities) and caches them so that it doesn't have to re-discover this information on every command.

This value is not intended to be changed, otherwise you risk problems like this.

To resolve this, you can stage a rename from one case to the other. For example, if you have a repository that contains a folder named foo and another folder named FOO. Imagine that you have two files, foo/bar and FOO/baz:

% git ls-files --stage
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0   FOO/baz
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0   foo/bar

To resolve this, decide which name you want to keep (foo or FOO) and rename the other. You'll need to use git mv with the -f flag:

% git mv -f FOO/baz foo/baz
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    FOO/baz -> foo/baz

You can check that in to resolve the problem.

If you have two files with the same name but that differ in case, you'll need to decide which name to keep.

% git ls-files --stage
100644 ba578e48b183662ddf9b38682cc52fb80066ce6d 0   FOO/bar
100644 5716ca5987cbf97d6bb54920bea6adde242d87e6 0   foo/bar

To remove the other file, use the --cached flag to git rm to prevent removing it from the disk.

% git rm --cached FOO/bar
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    FOO/bar

  • 1
    How would you fix this? – jessehouwing Feb 2 '19 at 11:40
  • @jessehouwing Your best bet may be finding the commit that introduced this and reverting it. Then smacking whoever it was. (Unfortunately, it won't be possible to smack the folks who made Windows case-insensitive.) – ceejayoz Feb 2 '19 at 14:08
  • 2
    I've updated this to include instructions for remedying it; I wouldn't advise reverting, since you probably want the content and there are probably multiple subsequent commits affecting that path. – Edward Thomson Feb 2 '19 at 17:24
  • Yeah this or a massive interactive rebase ;). I wonder whether the BFG Repo Cleaner has a switch for this. – jessehouwing Feb 2 '19 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.