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.

>
> Best regards,
> Sheng Yun
> --
>

> 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

>>> 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?

> (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 <jrnieder@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>

> 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.
>