Re: [PATCH v4 06/21] test-date: add a subcommand to measure times in shell scripts

Junio C Hamano [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

I think the goal to have our own stopwatch so that we do not have to
worry about differences among system-provided ones makes sense.

The only thing that may become an issue is how widely available
getnanotime() is.  As "test-date" itself is built on any platform an
end-user/developer runs our tests, which is wider set of platforms
than what we run Travis and other CIs on, unconditionally relying on
its availability might pose an issue.

Sorry for a false alarm, as the codebase in many places like
fsmonitor, progress, trace and wt-status have been assuming
getnanotime() to be available for quite some time, and this is just
another user of the same function.

And there was yet another misunderstanding on my part.  I thought
that the mention of getnanotime() was about

https://www.freebsd.org/cgi/man.cgi?query=getnanotime&sektion=9

and I did not realize that the hits I saw in "git grep getnanotime"
were referring to an unrelated function trace.c::getnanotime() of
our own.  Of course, it is safe to use that function in the tests
;-)

Again, sorry for the false alarm.

We _might_ get a complaint from freebsd devs when they want to use
their getnanotime(9) to implement highres_nanos(), and the cleanest
solution to that complaint will be to rename our own getnanotime()
to git_nanotime() or something, but (1) that is totally outside the
scope of this series that adds one more caller to the function and
(2) we can do that when we actually get such a complaint.