Re: USE_NSEC bug?

[Jeff King <peff@peff.net>]

On Wed, Mar 20, 2013 at 10:04:14AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > But maybe there is some subtle reason I'm missing for having the two
> > options separate.
> 
> The closest I found was c06ff4908bf9 (Record ns-timestamps if
> possible, but do not use it without USE_NSEC, 2009-03-04).
> 
> commit c06ff4908bf9ad8bf2448439a3574321c9399b17
> Author: Kjetil Barvik <barvik@broadpark.no>
> Date:   Wed Mar 4 18:47:40 2009 +0100
> 
>     Record ns-timestamps if possible, but do not use it without USE_NSEC
>     
>     Traditionally, the lack of USE_NSEC meant "do not record nor use the
>     nanosecond resolution part of the file timestamps".  To avoid problems on
>     filesystems that lose the ns part when the metadata is flushed to the disk
>     and then later read back in, disabling USE_NSEC has been a good idea in
>     general.
>     
>     If you are on a filesystem without such an issue, it does not hurt to read
>     and store them in the cached stat data in the index entries even if your
>     git is compiled without USE_NSEC.  The index left with such a version of
>     git can be read by git compiled with USE_NSEC and it can make use of the
>     nanosecond part to optimize the check to see if the path on the filesystem
>     hsa been modified since we last looked at.

Thanks, I suspected that might be the reason. IMHO it is not a big win,
as you would just refresh the index when using the version compiled with
USE_NSEC (so it really only helps you if you are frequently switching
between the two versions, which seems silly).

And the cost is that we have another Makefile knob people need to tweak
that would not otherwise need to be there. Which can be annoying, but is
also not that huge a cost to deal with (we might want to improve the
configure script or something, though).

I admit I don't care too much either way.

-Peff