Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.
Hi, I found git sometimes can't detect working trees changes. But I can only reproduce this problem on several specific files, unfortunately these files are copyrighted source files so I can't send them to you. Is there anything I can do to narrow the problem and finally reproduce the bug without these commercial files? I posted a question on stackoverflow which shows the process. http://stackoverflow.com/questions/22684163/cant-reproduce-a-bug-in-git-without-a-specific-file Actually what I'm doing is: git init copy the first version of file into the working tree. git add . git commit -m 'init' copy and replace the file into working tree. git status and nothing is reported by git. these two files have the same timestamp, the same size, bug slightly different contents. These files were generated by `git difftool -d` I just manually copied them out from the temp directory just for future review. Git I'm using is msysgit 1.9.0 on windows 7 Best regards, Sheng Yun -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.
On 28/03/2014 07:45, yun sheng wrote: Hi, I found git sometimes can't detect working trees changes. But I can only reproduce this problem on several specific files, unfortunately these files are copyrighted source files so I can't send them to you. Is there anything I can do to narrow the problem and finally reproduce the bug without these commercial files? I posted a question on stackoverflow which shows the process. http://stackoverflow.com/questions/22684163/cant-reproduce-a-bug-in-git-without-a-specific-file Actually what I'm doing is: git init copy the first version of file into the working tree. git add . git commit -m 'init' copy and replace the file into working tree. git status and nothing is reported by git. these two files have the same timestamp, the same size, bug slightly different contents. These files were generated by `git difftool -d` I just manually copied them out from the temp directory just for future review. Don't worry about copyright, please run sha1sum in order to make sure the content is changed! Git I'm using is msysgit 1.9.0 on windows 7 Is it Ok on Linux OS, on other git version? Best regards, Sheng Yun -- -- Trần Ngọc Quân. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.
Hi, yun sheng wrote: these two files have the same timestamp, the same size, bug slightly different contents. How did they get the same timestamp? [...] Git I'm using is msysgit 1.9.0 on windows 7 Unixy operating systems have other fields like inode number and ctime that make it possible to notice that a file might have been changed without actually rereading it. Unfortunately Git for Windows is limited to what's in the WIN32_FILE_ATTRIBUTE_DATA which means the size, mtime, and mode are basically all it has to go by. Do you know of some other Windows API call that could help? Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.
-- Forwarded message -- From: yun sheng uew...@gmail.com Date: Fri, Mar 28, 2014 at 9:28 AM Subject: Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code. To: Trần Ngọc Quân vnwild...@gmail.com The result of sha1sum is different. Following is my console log C:\shengy\tmp\shengyun\git-testgit init Initialized empty Git repository in C:/shengy/tmp/shengyun/git-test/.git/ C:\shengy\tmp\shengyun\git-testcopy C:\shengy\Dropbox\tmp\git-issue\old\epmdstyp.h 1 file(s) copied. C:\shengy\tmp\shengyun\git-testgit add . C:\shengy\tmp\shengyun\git-testgit commit -m 'init' [master (root-commit) 579385e] 'init' 1 file changed, 97 insertions(+) create mode 100644 epmdstyp.h C:\shengy\tmp\shengyun\git-testsha1sum epmdstyp.h c2310fe32891dc7269298814475d0ad083c5483c *epmdstyp.h C:\shengy\tmp\shengyun\git-testcopy C:\shengy\Dropbox\tmp\git-issue\new\epmdstyp.h Overwrite C:\shengy\tmp\shengyun\git-test\epmdstyp.h? (Yes/No/All): Y 1 file(s) copied. C:\shengy\tmp\shengyun\git-testsha1sum epmdstyp.h 7a98d5161b5e5ae201997b40fa5d5cebe1d14d1c *epmdstyp.h C:\shengy\tmp\shengyun\git-testgit status On branch master nothing to commit, working directory clean C:\shengy\tmp\shengyun\git-test On Fri, Mar 28, 2014 at 9:04 AM, Trần Ngọc Quân vnwild...@gmail.com wrote: On 28/03/2014 07:45, yun sheng wrote: Hi, I found git sometimes can't detect working trees changes. But I can only reproduce this problem on several specific files, unfortunately these files are copyrighted source files so I can't send them to you. Is there anything I can do to narrow the problem and finally reproduce the bug without these commercial files? I posted a question on stackoverflow which shows the process. http://stackoverflow.com/questions/22684163/cant-reproduce-a-bug-in-git-without-a-specific-file Actually what I'm doing is: git init copy the first version of file into the working tree. git add . git commit -m 'init' copy and replace the file into working tree. git status and nothing is reported by git. these two files have the same timestamp, the same size, bug slightly different contents. These files were generated by `git difftool -d` I just manually copied them out from the temp directory just for future review. Don't worry about copyright, please run sha1sum in order to make sure the content is changed! Git I'm using is msysgit 1.9.0 on windows 7 Is it Ok on Linux OS, on other git version? Best regards, Sheng Yun -- -- Trần Ngọc Quân. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.
The files get the same timestamp by using `git difftool -d` to view diffs, the diff tool I use id beyond compare 3, this command would generate temp files to feed the compare program, so these files get the same time stamp, I copied them out from the temp folder. I have no idea of the second quesiton, I am really not familiar with windows API. Do you mean this file may have been changed without rereading and git can't detect it? Best regards, Sheng Yun On Fri, Mar 28, 2014 at 9:40 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi, yun sheng wrote: these two files have the same timestamp, the same size, bug slightly different contents. How did they get the same timestamp? [...] Git I'm using is msysgit 1.9.0 on windows 7 Unixy operating systems have other fields like inode number and ctime that make it possible to notice that a file might have been changed without actually rereading it. Unfortunately Git for Windows is limited to what's in the WIN32_FILE_ATTRIBUTE_DATA which means the size, mtime, and mode are basically all it has to go by. Do you know of some other Windows API call that could help? Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git doesn't notice file has changed (Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.)
(cc-ing msysgit list, where there are more Windows-knowledgeable people) yun sheng wrote: On Fri, Mar 28, 2014 at 9:40 AM, Jonathan Nieder jrnie...@gmail.com wrote: yun sheng wrote: these two files have the same timestamp, the same size, bug slightly different contents. How did they get the same timestamp? [...] Git I'm using is msysgit 1.9.0 on windows 7 Unixy operating systems have other fields like inode number and ctime that make it possible to notice that a file might have been changed without actually rereading it. Unfortunately Git for Windows is limited to what's in the WIN32_FILE_ATTRIBUTE_DATA which means the size, mtime, and mode are basically all it has to go by. Do you know of some other Windows API call that could help? The files get the same timestamp by using `git difftool -d` to view diffs, the diff tool I use id beyond compare 3, this command would generate temp files to feed the compare program, so these files get the same time stamp, I copied them out from the temp folder. I have no idea of the second quesiton, I am really not familiar with windows API. Do you mean this file may have been changed without rereading and git can't detect it? Sorry for the lack of clarity. I meant that normally git detects when a file might have been changed without actually reading the file. To do this, it uses heuristics like If all file attributes are unchanged, the file is unchanged which tend to work well on Unix. My question was whether there's some similar trick that could work better on Windows than the current code. For example, if some interested person ports something like Facebook's watchman[1] to Windows[2], then Git could take advantage of that work using something like Duy's file-watcher series[3], which would be one way to fix this problem. Thanks, Jonathan [1] https://github.com/facebook/watchman [2] using FindFirstChangeNotification and ReadDirectoryChangesW, perhaps [3] http://thread.gmane.org/gmane.comp.version-control.git/240339/focus=241395 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't notice file has changed (Re: Found a bug in git 1.9.0 but can't reproduce it without copyrighted source code.)
The problem is I can't reproduce this bug if create some other files which have the same size and timestamp. It only happens on several files in my project. And it's even more frustrating that I can't send these files to the mailing list since it is a proprietary source file. On Fri, Mar 28, 2014 at 9:59 AM, Jonathan Nieder jrnie...@gmail.com wrote: (cc-ing msysgit list, where there are more Windows-knowledgeable people) yun sheng wrote: On Fri, Mar 28, 2014 at 9:40 AM, Jonathan Nieder jrnie...@gmail.com wrote: yun sheng wrote: these two files have the same timestamp, the same size, bug slightly different contents. How did they get the same timestamp? [...] Git I'm using is msysgit 1.9.0 on windows 7 Unixy operating systems have other fields like inode number and ctime that make it possible to notice that a file might have been changed without actually rereading it. Unfortunately Git for Windows is limited to what's in the WIN32_FILE_ATTRIBUTE_DATA which means the size, mtime, and mode are basically all it has to go by. Do you know of some other Windows API call that could help? The files get the same timestamp by using `git difftool -d` to view diffs, the diff tool I use id beyond compare 3, this command would generate temp files to feed the compare program, so these files get the same time stamp, I copied them out from the temp folder. I have no idea of the second quesiton, I am really not familiar with windows API. Do you mean this file may have been changed without rereading and git can't detect it? Sorry for the lack of clarity. I meant that normally git detects when a file might have been changed without actually reading the file. To do this, it uses heuristics like If all file attributes are unchanged, the file is unchanged which tend to work well on Unix. My question was whether there's some similar trick that could work better on Windows than the current code. For example, if some interested person ports something like Facebook's watchman[1] to Windows[2], then Git could take advantage of that work using something like Duy's file-watcher series[3], which would be one way to fix this problem. Thanks, Jonathan [1] https://github.com/facebook/watchman [2] using FindFirstChangeNotification and ReadDirectoryChangesW, perhaps [3] http://thread.gmane.org/gmane.comp.version-control.git/240339/focus=241395 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
