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
# modifi开发者_运维百科ed: 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?
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.
This made me wonder wether this was a clock problem on the computer. Setting the time on the server to
-1h
does not help.
BTW, gitx and git-gui work perfectly through sshfs on the same two machines (but, even though convenient, sshfs is not as fast as samba on a local network).
Locking issue has been known to happen when cloning a repo over samba share.
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.
精彩评论