Enable nanosecond resolution by default #3655
Conversation
Nanosecond resolution is now the default in git itself. Enable this as our default as well.
|
The ones building "Release" fail... should we be worried this is a timing bug in the test suite or the library? |
Update unit test to use newfangled `st_ctime_nsec`, which provides indirection to the platform-correct name.
If the underlying filesystem doesn't support better than one second resolution, then don't expect that turning on `GIT_USE_NSEC` does anything magical to change that.
e09cba3 to
a6cea96
Compare
Instead of hoping that we can get a racy entry by going real fast and praying real hard, just create a racy entry.
a6cea96 to
53fb823
Compare
|
Indeed it was a timing bug in the test suite. We were trusting that we could do a bunch of operations really quickly to get ourselves a racy entry in the index - which is complete horseshit buuuuut it also happens to be true on most filesystems because they have shit resolution. Instead of doing stuff real fast and hoping that it works out, I twiddled the index's timestamp, so we now invent some raciness instead. |
Enable nanosecond resolution by default
|
Changing the default regressed performance of things like |
|
@hackhaslam Hmm. We haven't seen anything like this, and everything certainly seems normal to me. (Faster, in fact, since there's better resolution on some platforms.) Please do open a new issue if you think that there's a problem, but please provide plenty of details. A broken index would be helpful, as would information about the client that created it and the client that is deciding that everything's dirty. Is the slow client in question actually an old version of libgit2? Are you running into #3480 ? |
|
No, it's not an old version. I'm using the tip of master. I will look more closely to see if I can provide some more details. |
|
Okay, maybe I misunderstood your question. It turns out that the index (or at least the index of some rather large submodules) was written with an old version of git (1.8.4). After rebuilding the indexes of all of the submodules with a new version of git the problem goes away. So presumably, older versions of git wrote an index without nanosecond resolution and now I'm trying to compare it with stats of nanosecond resolution? Is there any way that I can detect this at runtime and only compare nanoseconds if the index has nanosecond resolution? |
|
Aha. You didn't misunderstand, my first guess was incorrect. But that makes sense. We're quite obviously behaving incorrectly here, but at least it makes sense. :) This is the opposite problem that we were stuck with when git itself turned on nanoseconds and we were unprepared. Now we're expecting nanoseconds always, it appears. What we should be doing here is detecting that the index doesn't have nanoseconds and falling back to non-nanosecond behavior. Looks like we're screwing that one up. I'm afraid that I can't fix this today - but feel free to open an issue and I should be able to get to it later this week. Thanks for the report! |
|
Thanks! I added #3754. |
Nanosecond resolution is now the default in git itself. Enable this
as our default as well.