Re: [PATCH] t1016-compatObjectFormat: Really freeze time for reproduciblity

From: Todd Zullinger <tmz@pobox.com>
Date: Oct 29, 2025, 03:05 UTC
Message-ID: <aQGEl6Y-BaHsLphW@teonanacatl.net>
In-Reply-To: <xmqqv7jzc5hw.fsf@gitster.g>

Junio C Hamano wrote:

> "Eric W. Biederman" <ebiederm@xmission.com> writes:
> 
>> 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/

Show 14 quoted lines

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