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
> 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
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
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
For more options, visit https://groups.google.com/d/optout.