Re: [PATCH 0/3] Win32: nanosecond-precision file times

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]