5

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
John Munsch
  • 19,530
  • 8
  • 42
  • 72
  • 1
    Could you provide some more info? What's in the user's .git/config file under the project folder? Do you know what Git commands are being executed (`git pull` or `git pull origin master` are most common). Have other user's in the group reproduced the exact steps with different outcomes? Is there one .git directory under the project folder and no other sub-folders? – Go Dan Oct 04 '11 at 21:04
  • 1
    Is this some case issue, where somehow the case is different, a bit like in http://stackoverflow.com/questions/52950/how-to-make-git-ignore-changes-in-case ? (what is the value of `git config core.ignorecase`? It should be true by default, but if it is false... that could explain it. – VonC Oct 04 '11 at 21:14
  • 1
    Also, did you use `git log -- untracked_file` to check the log? – manojlds Oct 04 '11 at 21:26
  • Assuming git log untracked_file and git log -- untracked file are the same thing, then yes. That's how we noticed the weird discrepancy. The git log for the entire project listed commits that included the files (the ones that had added them to the files locally in the first place) and yet the git logs for the individual files that it now thinks are untracked have no history at all. So it's like it has Alzheimers about where they came from. – John Munsch Oct 04 '11 at 21:43
  • @John: They're not exactly the same thing, but if you currently have an untracked file "foo", and there used to be a file "foo" tracked by git, then the two should do the same thing, I believe. As for answering your question, I think you're going to have to provide more detail, like an exact sequence of events and/or some actual log and status output. – Ryan Stewart Oct 05 '11 at 04:56

2 Answers2

2

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

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • I totally agree with you regarding setting this to default. My colleagues are suffering... – cJ Zougloub Oct 05 '11 at 01:14
  • I can definitely see how that would result in it thinking that files retrieved via a pull had "changed" even when they hadn't been touched, but would that really fool Git into thinking that the files were new and untracked? It should still know that the file had been there before and from whence it came. – John Munsch Oct 05 '11 at 03:45
  • I cannot understand how this answers the OP's question for his situation. Where does `untracked` come into the picture at all? Where does not showing the file in the log at all come fit into this answer? – manojlds Oct 05 '11 at 04:33
  • 1
    Changed the answer and added a few more ideas and problems I've ran into. let us know how it goes. – Adam Dymitruk Oct 05 '11 at 04:33
0

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.

John Munsch
  • 19,530
  • 8
  • 42
  • 72