Junio C Hamano wrote:

"Eric W. Biederman" [off-list ref] writes:

quoted

By default gpg still allows time to move forward with --faked-system-time.
So in those rare instances when the system is heavily loaded an gpg runs

s/an/&d/

quoted

slower than other times, signatures over the exact same data differ
due to timestamps with a minuscule difference.

Reading through the gpg documentation with a close eye, time can be
frozen by including an exclamation point at the end of the argument to
--faked-system-time.
...
 t/t1016-compatObjectFormat.sh | 6 ++++++
 t/t1016/gpg                   | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

Geez, how are we expected to find the need for '!' ourselves X-<.

Thanks for root causing the issue so quickly once it was raised.

I'll second that.  Nicely sleuthed and explained.

It explains why I had trouble that I thought looked like gpg
wasn't setting the time as expected, long before the code
change which caused the custom gpg wrapper to not be used by
all the tests.

Back then, I went so far as to run the whole test suite with
the gpg wrapper setting --faked-system-time, but I didn't
notice the crucial lack of an exclamation point on the time
either.

I applied this and Junio's previous patch to ensure the
wrapper is always used on top of 2.51.2¹ and ran it through
the Fedora build system where I consistently saw failures
before.  With this patch it all worked as expected.

¹ It's much easier for me to test a released tarball with
  the existing Fedora packaging than a snapshot of next;
  even though I know it's of *slightly* less value than
  testing the tip of next or seen.

Thanks!

-- 
Todd