You can clone with
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
.../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(-)
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
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.
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.
core.ignorecase = true
This may have introduced the problem: 1fe532e -- particularly the change to GitRepository.cs.
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.
Fix issue #159
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
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)
If this is not fixed, please re-open.
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
@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.
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.
I have the problem just as jmaxxz describes. Does anyone have a workaround?
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.