On Thursday, February 5, 2015 at 3:05:08 PM UTC+1, Thomas Ferris Nicolaisen 
> On Thursday, February 5, 2015 at 2:31:54 PM UTC+1, J66st wrote:
>> Thomas, thanks for your time!
>> I prepared a new minimal demo package with a shell script to easily 
>> install my test-repository and run the test.
>> Please download the attached Demo.zip, unpack it in a clean directory.
>> It contains two files: DixiLink2.zip (this is my test-repository) and a 
>> shell script "weird-git-demo".
>> Run the shell script from that directory. Script logging is enabled, so 
>> you will see what happens.
>> The script will unpack the repository in a subdirectory DemoRepo, do some 
>> log, status and diff commands to prove what seems wrong.
> OK, just to give some quick feedback on this; I see the same problem on my 
> Windows when I run your script. I don't see it on OSX. 
> If I unzip the DixiLink2.zip using Git Bash's unzip command, I can 
> recreate it.
> If I use 7zip or Windows built-in extractor to unzip, I don't get the 
> problem.
> If I do have the problem, a simple "touch dixilinkerr.h" will solve it.
> So I think it is a bit like I suspected. Git status somehow converses with 
> a part or API of the filesystem (cache) that is not up to speed with the 
> actual contents of the file.
> I've recreated an OSX directory to my virtual Windows XP, and whereas I 
> can see git status doing the wrong thing on Windows, on OSX it's acting 
> fine in the same actual directory. Any modification of the file from either 
> system will correct the issue, it seems.
Thanks for your quick feedback!

After running the demo in bash, I opened a fresh CMD prompt, and did a git 
status. It still reports a clean working directory. Even a Windows reboot 
won't help.

My opinion: There is no caching between the Windows filesystem and 
git which is causing the problem. When I run Git commands from bash I can 
easily prove (thru Git itself) that the working directory is dirty. So Git 
could see for itself.
What I think is wrong: Git might have some private cache (where? in the 
binary index file?) where it keeps the timestamp of a file. *If the length 
AND the timestamp of a file matches the cached data, it assumes that the 
file is unchanged.* Obviously it does not inspect the file's contents or 
recalculate the hash when I ask for a diff! That's bad! (That also explains 
why touching the file or using a different unzip tool helps: they change 
the file's timestamp).
So I consider this a serious bug in Git for Windows.

I will go and look for the mailinglist to report this. Thanks very much for 
your help!

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to