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

Question

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
    logallrefupdates = 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

Answer 1

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.