git 未检测到某些文件的更改
我已设法使索引处于某些文件未按预期跟踪的状态。
作为一个例子,我在工作目录中没有修改 size.h 和 test.h:
$ git-ls-files -st size.h test.h
H 100644 de2c741b07d86f92bdd660626848072cb2bf510f 0 size.h
H 100644 8bb24bc7483ffcfc0fc1a3761dc63e86a1b3e003 0 test.h
$ git status
# On branch master
nothing to commit (working directory clean)
然后我对这两个文件进行一些随机更改:
$ fortune >> size.h
$ fortune >> test.h
由于某种原因, size.h 没有被修改(尽管该文件显然是)。同时,test.h 按预期进行了修改:
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: test.h
#
no changes added to commit (use "git add" and/or "git commit -a")
删除索引并重置后,一切都恢复正常:
$ rm .git/index
$ git reset
Unstaged changes after reset:
M size.h
M test.h
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: size.h
# modified: test.h
#
no changes added to commit (use "git add" and/or "git commit -a")
在奇怪之前,我一直在 CentOS 上使用 git 1.6.6,在 Windows 上使用 msysgit 1.6.5.1 通过 samba 在此存储库上工作出现了。我无法从新的克隆中重现这一点。
我的直觉是这是 msysgit 中的一个错误,可能与 samba 结合在一起。有什么想法吗?
I have managed to get my index in state where some files aren't tracked as expected.
As an example I have size.h and test.h unmodified in the working directory:
$ git-ls-files -st size.h test.h
H 100644 de2c741b07d86f92bdd660626848072cb2bf510f 0 size.h
H 100644 8bb24bc7483ffcfc0fc1a3761dc63e86a1b3e003 0 test.h
$ git status
# On branch master
nothing to commit (working directory clean)
Then I do some random change to both files:
$ fortune >> size.h
$ fortune >> test.h
For some reason size.h is not modified (although the file clearly is). At the same time test.h is modified as expected:
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: test.h
#
no changes added to commit (use "git add" and/or "git commit -a")
After removing the index and resetting everything is back to normal:
$ rm .git/index
$ git reset
Unstaged changes after reset:
M size.h
M test.h
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: size.h
# modified: test.h
#
no changes added to commit (use "git add" and/or "git commit -a")
I have been working with git 1.6.6 on CentOS and msysgit 1.6.5.1 on Windows over samba on this repository before the strangeness appeared. I have not been able to reproduce this from a fresh clone.
My gut feeling is that this is a bug in msysgit, maybe in combination with samba. Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我见过的唯一一个通过 samba 显示 Git 错误状态的错误是 GitX票147。
这是相反的情况(git status 显示未修改的文件的修改),但表明文件的某些元素(大小?日期?权限?)未通过 samba 共享正确传输。
已知在克隆存储库时会发生锁定问题桑巴分享.
The only bug I have seen which also display the wrong status for a Git over samba is the GitX ticket 147.
It is about an opposite situation (git status shows modification for a file which has not been modified), but suggests that some elements of the file (size? date? rights?) are not properly transmitted through the samba share.
Locking issue has been known to happen when cloning a repo over samba share.
我在版本 1.7.9.msysgit.0 中遇到了这个问题。
问题是我已将项目移动到一个新目录,并且至少我的一个子模块具有工作树的绝对路径。
一旦我删除了子模块目录,删除了 .git/modules 中的条目,并重新初始化和更新了它们,问题就消失了。
这很奇怪,因为 git 在检查项目状态时绝对没有给出错误或警告消息(我可以看到),只有当我执行 git submodule update --init 时,它才会向我显示无法访问的错误它想要走的路。
I was experiencing this problem with version 1.7.9.msysgit.0
The problem was that I had moved the project to a new directory, and atleast one of my submodules had an absolute path for the worktree.
Once I removed the submodule directories, deleted their entries in .git/modules, and re-initialized and updated them, the problem went away.
This was odd because git gave absolutly no error or warning message (that I could see) when checking status of the project, only when I did a git submodule update --init would it show me the error that it couldn't get to the path it wanted to.