Git 是否应该认为从拉取中获得的文件现在未被跟踪？
我们的一位开发人员在使用他的 Git 存储库时一直遇到问题。他拉取，然后“git status”显示了实际上来自他上次拉取的未跟踪文件的完整列表（即，Git 认为它们是新的）。实际上，您可以返回查看他的 git 日志并指定添加它们的特定提交，并且它在他的历史记录中。但是，如果您转到现在未跟踪的文件之一并对其执行 git log，则根本没有历史记录。
我绝对很困惑。小组中的每个人，包括我，都是 Git 新手，所以我不能排除他可能在某个地方犯了错误，但这似乎不太可能。就像他的存储库不断损坏一样。
他使用的是 msysgit 1.7.6 和 Tortoise Git 1.7.3。我们在 myEclipse 中使用 eGit 一段时间，它反复崩溃，所以早期的问题都归咎于此。现在，我认为没有人再使用它了，所以我觉得我不能再责怪 eGit 了。
我需要 Stack Overflow 的 Git 专家的帮助！可能是什么原因造成的？有什么情况下这是正常的吗？
根据请求，这里是已损坏的存储库的 .git/config 文件：
[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 = [email protected]
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 = [email protected]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看 git-dir 环境变量是否已更改。工作树变量也是如此。还要看看您是否确实与您想象的位于同一目录中。您正在使用 tortoisegit，这可能是您正在查看的目录与命令行不同的目录。
另外，当您通过 CD 到文件以查看它是否存在时，请确保您使用制表符完成目录名称，因为 msysgit 很乐意处理文件/目录，无论大小写如何。然而 Git 很关心。
可以到达，
并且路径将反映这一点。
现在 git status 将显示有一个文件未被跟踪，因为 git 会将
mydir/somefile视为与MYDIR/somefile不同的东西。有时很难看出，因为只需在文件的整个路径中存在一个大小写差异即可获得此行为。现在请坚持使用命令行来解决此问题。在 tortoisegit 和命令行之间切换对这种情况没有帮助。
你能启动一个新的存储库并看看它是否可以单独在命令行上重现吗？
希望这有帮助，
亚当
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.
can be reached by
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/somefileas something different thanMYDIR/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
我们从来没有“解决”这个问题。但是，我们确实停止使用远程目录来存储共享存储库。它从来都工作得不好，它使用的是 Novell 或某些 Windows 网络解决方案，速度非常慢，而且我们经常看到这样或那样的问题。
现在，我无法证明不寻常的设置是我们所有问题的原因，但是，我设置了 GitBlit 作为我们可以与之对话的 Git 服务器。在我这样做之后，我们对服务器采取的每项操作实际上都快了一个数量级，而且我们再也没有遇到过损坏问题。
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.