CODEWITHSUNDEEP
gittfs
Arkadiusz Kałkus
Arkadiusz Kałkus

Reputation: 18423

Git has split single directory into two on the TFS server

I have some Git repository hosted on TFS. I've developed it for some time and during configuration of CD our team noticed that part of the project is split into two directories. One is written in uppercase, second in camelcase. I thought it's just some merging issue. But... two directories are visible only on TFS web portal when code is browsed. Cloning it (on Windows machine) produce just single (uppercase) directory. Moreover on TFS the directory content is partly in first, partly in second directory.

What can be the reason? It if would be Linux Git server I'd guess it might be some file system difference. But it's Windows TFS server.

UPDATE

It seems that during development the directory has been renamed from UPPERCASE to CamelCase. What is interesting is that TFS offers zip file download not only cloning. In zip file there's single directory. But inside directory there are two files (also renamed). During unzipping zip asks for replacement of one file. It looks like git case sensitivity vs. windows case insensitivity issue.

Upvotes: 4

Views: 61

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45769

As you may know, internally git filenames (including directory names) are just text in a TREE object, which is more or less a compressed text file representing a directory listing. So that's case sensitive.

As you do know (and pointed out), Windows file system is not case sensitive.

There are a collection of work-around built into git, controlled by the core.ignoreCase config option, which help to mitigate the mismatch. They aren't perfect, but for the most part if everybody uses this setting correctly and nobody goes out of their way to thwart it, it's enough to usually keep bad things from happening.

It's possible that someone didn't have this set correctly, or did some work on a case-sensitive system where they had turned core.ignoreCase off, or typed a git add command explicitly using contradictory case from what was, at the time, in the database. It's hard to list out the exact scenarios in detail, but the point is, again, the work around isn't perfect. So it could happen.

And from there, bad things can happen, because the two trees representing the different-case names can have conflicting content within a version. So while it may or may not be worth a history rewrite, it probably is worth fixing at the branch tip(s).

By the way, the reason you see this in the UI but not in a downloaded ZIP is, TFS almost assuredly checks the commit out (to a case-insensitive file system) as the first step in generating the ZIP for download; whereas the UI probably draws directly from the objects in the repo database.

Not sure there's much more to say, unless you have follow-up questions.

Upvotes: 2

Related Questions