[git-users] Re: Weird integrity problem?
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. -- 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.
[git-users] Re: Weird integrity problem?
On Thursday, February 5, 2015 at 12:44:37 AM UTC+1, J66st wrote: Adding another snippet to the previous post. The failure occurs in the DixiLink2/ directory. Then I clone the directory to DixiLink6/ : there everything works fine. A directory of tree compare shows not a single difference, in contents nor in attributes. (Well, could there be a difference in some alternative stream, this is NTFS.) Sorry for the lengthy posts. I skimmed across your findings, and by the looks of it there is something really strange going on. Am I correct in understanding that zipping and then unzipping the directory fixed it in one case? In another example, you fixed it by renaming the file twice? How do you effectively reproduce the issue in another folder? Just a simple copy of the folder where the problem originated? Since the problem seems somewhat ephemeral, and goes away when doing some simple file operations, I tend to think that this has something to do with NTFS. Perhaps Git is getting some kind of cached value from the file system when doing diff/status, while you get the actual real contents when manually reading the file. Can you recreate the issue on different disk (USB stick)? What if it's FAT32 formatted? Perhaps it would be good to have someone from the Git for Windows mailing list see if they recognize this problem. -- 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.
[git-users] Re: Weird integrity problem?
On Thursday, February 5, 2015 at 3:05:08 PM UTC+1, Thomas Ferris Nicolaisen wrote: 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.
[git-users] Re: Weird integrity problem?
https://lh6.googleusercontent.com/-8q5X6kVeArA/VNKyzDA3ezI/AV8/L4iB9wSTkR8/s1600/gitk-patch-view.png -- 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.
[git-users] Re: Weird integrity problem?
On Friday, January 23, 2015 at 6:11:54 PM UTC+1, J66st wrote: Working with git now for a few weeks, and trying to move my Visual SourceSafe repositories to git. I am encountering a weird problem. I have set up a small example repo (see the attached zipfile). Containing a single file dixilinkerr.h. There are three versions of this file. v1: Contains a #pragma message line, and a #define CAT_DIXILINK_ERR v2: Edit: the #pragma message line is removed. v3: Edit: the symbol CAT_DIXILINK_ERR is replaced by EXCPCAT_DIXILINK Watching the repository and working directory in the current state: *git status*: nothing to commit, working directory clean. *git log* shows 2 commits: v1 and v2. *gitk* shows 2 commits: The first one in the root commit is v1. But the second one shows different result depending on the chosen view: *gitk Patch* view: the last commit is a patch from v1 to v3! (So bypassing v2!!) *gitk Tree* view: the last commit is v2 THIS IS WEIRD! *git show HEAD:dixilinkerr.h* Shows v2. So the strange thing is: v3 is not really in the repository. If you check out the latest version you get v2. v3 is in my working directory. But git does not see any changed files, and the index is empty. Git commit won't add the file. So the file is kind of halfway checked in... I ran into this problem several times when checking in thousands of files using a script. It seems to happen only when the file size of the two last versions of a file are equal but the contents differ. In the above example the v2 and v3 versions of the file have the same size. I am using msysgit version 1.9.0 on Windows 7. Is this a bug or am I missing something? As far as I can see, you have only committed this file twice. So there is no v3, there is only the uncommitted/unstaged changes in your working directory. gitk displays uncommitted changes with the message Local uncommitted changes, not checked in to index. So there is no v3. You have to commit first. Read through http://git-scm.com/book/en/v2/Getting-Started-Git-Basics and things should become a bit clearer. -- 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.
