Should Git ever think a file that it got from a pull is now untracked?

One of our developers keeps having problems with his Git repositories. He pulls and then later "git status" shows a whole list of untracked files (that is, Git thinks they are new) that actually came from his last pull. You can actually go back through his git log and specify the particular commit that added them and it's in his history. However, if you go to one of the now untracked files and do a git log on it, there's no history at all.

I'm absolutely mystified. Everybody in the group, including me, is new to Git so I can't rule out that he might be making a mistake somewhere, but it seems unlikely. It's like his repository keeps becoming corrupt.

He's using msysgit 1.7.6 and Tortoise Git 1.7.3. We were using eGit with myEclipse for a while and it crashed repeatedly so the early problems were all blamed on that. Now, I don't think anyone is using it anymore so I don't feel like I can blame eGit any longer.

I need the help of the Git gurus of Stack Overflow! What could be causing this? Is there any circumstance under which this would be normal?

Per request, here is the .git/config file for the repository which became corrupted:

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdat开发者_StackOverflowes = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = G:\\DotcomB
    puttykeyfile = 
[branch "master"]
    remote = origin
    merge = refs/heads/master
[user]
    name = jsmith
    email = JoeSmith@somewhere.com

See if the git-dir environment variable has been changed. Likewise the working tree variable. Also see if you are actually in the same directory as you think. You are using tortoisegit and that may be a different directory that you are looking at vs the command line.

Also, when you CD to the file to see if it's there, make sure you tab-complete the directory names as msysgit is happy to treat the file/directory no matter what the casing is. Git, however cares.

mydir/somefile

can be reached by

cd MYDIR

and the path will reflect that.

Now git status will show that there is a file that is not tracked because git will see mydir/somefile as something different than MYDIR/somefile. Sometimes it's hard to see because all it takes is one case difference in the whole path to a file to get this behaviour.

Stick to the command line for now to get this resolved. Bouncing between tortoisegit and the command line could not be helping the situation.

Can you start a new repository and see if it can be reproduced on the command line alone?

Hope this helps,

Adam

We never did "solve" this issue. However, we did stop using a remote directory to store the shared repositories. It never worked well, it was using Novell or some Windows networking solution that was slow as heck, and we regularly saw problems of one sort or another.

Now, I cannot prove that the unusual setup was the cause of all of our problems, but, I setup GitBlit as a Git server we could talk to instead. After I did that every action we took with the server was literally an order of magnitude faster and we have never seen the corruption problem again.