Am 13.02.2015 um 00:38 schrieb Junio C Hamano:
> Karsten Blees <karsten.blees@xxxxxxxxx> writes:
>
>> This is more about copying 'old' things around, which usually also
>> copies mtime on Windows. E.g.:
>>
>> # create two files with slightly different mtime
>> for i in {1..10}; do (echo "v1" >> test); done &&
>> for i in {1..10}; do (echo "v2" >> test2); done
>> # wait a bit so that '.git/index' is always newer than 'test' / 'test2'
>> sleep 1
>> git add test
>> git commit -m v1
>> # copy test2 over test (similar to 'cp -p', but native 'copy' also
>> # copies mtime nanoseconds)
>> cmd //c "copy /y test2 test"
>> git add test
>> git commit -m v2
>>
>> Without these patches, git does not detect the change, and the second
>> git add / git commit are noops.
>
> We do have sec/nsec fields in cache_time structure, so I have
> nothing against updating the msysGit port to fill that value.
>
> I was and am just reacting to the fact that this is sold as if it
> "fixes" something.
Sorry, that must have been a misunderstanding. This series does
NOT fix the problem with VSS2Git, nor any other tool that abuses
mtime for the author's birthday or whatever.
The issue that two files may accidentally have the same size and
mtime was just brought up in this discussion.
> It doesn't fundamentally change the fact that
> mtime that does not follow the semantics Dscho mentioned in his
> earlier message does not work well with Git.
>
> Having said that, even with such a patch, as long as the system is
> sufficiently fast, test and test2 will have nonoseconds identical
> timestamp and you would have the same issue, no?
>
Right. Where "sufficiently fast" would mean opening and closing a
file ten times in less than 100ns...on Windows... ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html