Skip to content
This repository

Clone does not track files correctly if committed with different case in pathname #159

perfp opened this Issue · 13 comments

6 participants

Per-Frode Pedersen ivan-danilov Matt Burke Jmaxxz Victor Perez Richard Bogle
Per-Frode Pedersen
perfp commented

I had a strange case where two files was commited to TFS, and then the folder of these files were renamed to the same name with differing case before more files were added to the folder. This leads to the unfortunate situation where git cannot track some of the files in the folder, since git is case sensitive while tfs isn't.

The simple workaround would be to perform a rename in TFS, but since it can be quite difficult to figure this one out, I'm submitting it here


C:\source\Project>git tfs pull
C2511 = ce456058982e4b8e936b350f8900eb077ca9a300
Updating fcdeaf9..ce45605
 .../Scripts/jquery/datepick/jquery.datepick-en.js  |    3 ++-    
 .../Scripts/jquery/datepick/jquery.datepick-no.js  |    3 ++-
 .../Scripts/jquery/datepick/jquery.datepick.js     |    3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

C:\source\Oti>git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#       app/Project.Web/Scripts/jquery/datePick/jquery.datepick-en.js
#       app/Project.Web/Scripts/jquery/datePick/jquery.datepick-no.js
#       app/Project.Web/Scripts/jquery/datePick/jquery.datepick.js
nothing added to commit but untracked files present (use "git add" to track)

Both git and TFS are case-sensitive. At least they store data (including filenames) in case-sensitive way. For git there's config setting core.ignorecase (which is true by default), that tells it to ignore changes if only casing is different. It seems you have this setting turned off for whatever reason.

Matt Burke

IIRC, TFS isn't always case-sensitive. It treats "$/PROJECT/FILE" and "$/Project/File" as the same item.


I believe it will service requests to both in the same way, but internally it is case-sensitive. At least, renaming files when only casing is changed is done correctly under TFS. And, btw, it becomes incorrect after git-tfs fetching - iff core.ignorecase = true. I faced this several days ago when Java-developer asked me about this thing because they have strict rules that filename should match class name exactly, including casing.

Matt Burke

This may have introduced the problem: 1fe532e -- particularly the change to GitRepository.cs.

Matt Burke

So then, maybe the problem is the case-insensitive Windows filesystem. Git's trees are case sensitive. So if the git tree has


then it gets confused about casing? I know that I've seen TFS serve up changesets in a way that makes this kind of tree possible, I think sometimes even within the same changeset, and that just ends up confusing git on Windows.

The reason the initialTree had a case-insensitive comparer was so that it could find cases like this, and translate paths like the above so that both files would end up either in DIR or dir in the git tree. I'm somewhat ambivalent about core.ignorecase.

Björgvin Ragnarsson nifgraup referenced this issue from a commit in nifgraup/git-tfs
Björgvin Ragnarsson nifgraup Fix issue #159 4dcfb0f

Has this fix made it into a release yet? I think I am also encountering this issue, as after doing:

git tfs pull
git reset --hard
git clean -f -d -x
git status

I see 90 untracked files. If I add these files to get them out of my git status log when I do a

git tfs ct
git tfs shelve "bla bla bla"

git tfs will fail telling me files already exist in tfs. I am guessing there is some bad book keeping going on here, could it be this casing issue? (it should be noted that I also end up with untracked files following a fresh quick-clone)

Matt Burke

If this is not fixed, please re-open.

Matt Burke spraints closed this
Victor Perez

There is a regression bringing this issue back for commits after tag v0.14.0, I can't really do a full bisect because it only happens when I clone a full repository and that takes me about 7 hrs with latest

Matt Burke

@vperez-rwserver could you write a test for CloneTests that demonstrates the problem? If you need help adding assertions or other helpers, I'm happy to help: just write some pseudo-code and we can iterate on getting it to be executable.

Victor Perez

I would love to help, but as I explained it is very hard to find the edge case that is causing this on our TFS repo because git-tfs clone takes me around 7 hrs. I tried cloning only one of the folders which ended with untracked files, but it seems the TFS changeset causing this issue only gets applied on a clone of the full project.

I am thinking that maybe adding a call to "git status" after clone gets each TFS changeset and abort if untracked files are found. This would help find the TFS changeset causing this issue so I can bisect faster.

Matt Burke
Richard Bogle

I have the problem just as jmaxxz describes. Does anyone have a workaround?

Matt Burke

is filename casing the problem? one way to spot it is, after adding and committing all the untracked files, view the tree for your HEAD and look for dirs (at any level) with the same name but different case. Do you know what combination of TFS changesets (or changes within a changeset) lead to this problem? You shouldn't need to redo your clone,, but if you take one of the affected dirs, you should be able to find where, in both the git and tfs histories, the problem comes from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.