Found a "bug" in git 1.9.0 but can't reproduce it without copyrighted source code.

Found a "bug" in git 1.9.0 but can't reproduce it without copyrighted source code.

[yun sheng]

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

Re: Found a "bug" in git 1.9.0 but can't reproduce it without copyrighted source code.

[Trần Ngọc Quân]

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.

Fwd: Found a "bug" in git 1.9.0 but can't reproduce it without copyrighted source code.

[yun sheng]

---------- Forwarded message ----------
From: yun sheng <uewing@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 <vnwildman@gmail.com>


The result of sha1sum is different. Following is my console log


C:\shengy\tmp\shengyun\git-test>git init
Initialized empty Git repository in C:/shengy/tmp/shengyun/git-test/.git/

C:\shengy\tmp\shengyun\git-test>copy
C:\shengy\Dropbox\tmp\git-issue\old\epmdstyp.h
        1 file(s) copied.

C:\shengy\tmp\shengyun\git-test>git add .

C:\shengy\tmp\shengyun\git-test>git commit -m 'init'
[master (root-commit) 579385e] 'init'
 1 file changed, 97 insertions(+)
 create mode 100644 epmdstyp.h

C:\shengy\tmp\shengyun\git-test>sha1sum epmdstyp.h
c2310fe32891dc7269298814475d0ad083c5483c *epmdstyp.h

C:\shengy\tmp\shengyun\git-test>copy
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-test>sha1sum epmdstyp.h
7a98d5161b5e5ae201997b40fa5d5cebe1d14d1c *epmdstyp.h

C:\shengy\tmp\shengyun\git-test>git 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 <vnwildman@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.
>

Re: Found a "bug" in git 1.9.0 but can't reproduce it without copyrighted source code.

[Jonathan Nieder]

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

Re: Found a "bug" in git 1.9.0 but can't reproduce it without copyrighted source code.

[yun sheng]

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

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

[Jonathan Nieder]

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

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

[yun sheng]

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