Re: [PATCH v2 1/2] t7508: add tests capturing racy timestamp handling

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 5, 2022, 20:59 UTC
Message-ID: <xmqqczl5hpaq.fsf@gitster.g>
In-Reply-To: <7d58f80611193f8696d99e317fe6b1e53ac740f7.1641388523.git.gitgitgadget@gmail.com>

"Marc Strapetz via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 30 quoted lines

> From: Marc Strapetz <marc.strapetz@syntevo.com>
>
> "git status" fixes racy timestamps regardless of the worktree being
> dirty or not. The new test cases capture this behavior.
>
> Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
> ---
>  t/t7508-status.sh | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
> index 05c6c02435d..652cbb5ed2e 100755
> --- a/t/t7508-status.sh
> +++ b/t/t7508-status.sh
> @@ -1656,4 +1656,32 @@ test_expect_success '--no-optional-locks prevents index update' '
>  	! grep ^1234567890 out
>  '
>  
> +test_expect_success 'racy timestamps will be fixed for clean worktree' '
> +	echo content >racy-dirty &&
> +	echo content >racy-racy &&
> +	git add racy* &&
> +	git commit -m "racy test files" &&
> +	# let status rewrite the index, if necessary; after that we expect
> +	# no more index writes unless caused by racy timestamps; note that
> +	# timestamps may already be racy now (depending on previous tests)
> +	git status &&
> +	test-tool chmtime =1234567890 .git/index &&
> +	test-tool chmtime --get .git/index >out &&
> +	grep ^1234567890 out &&

If file contents were 1234567890999, this will still hit, but I do not think that is what you wanted to see. Perhaps

	git status &&
	echo 1234567890 >expect &&
	test-tool chmtime=$(cat expect) .git/index &&
	test-tool chmtime --get .git/index >actual &&
	test_cmp expect actual

or something? But I think you inherited this bogosity from the previous test, so I am OK to add a few more copies of the same bogosity to the test.

Somebody later has to step in and clean them all up, though. When that happens, we should document how the magic 1234567890 timestamp was chosen near its first use.

I think it is because it is a timestamp in year 2009, so as long as your filetime clock is reasonably accurate, a write to the file would never get such a low timestamp.

> +	git status &&
> +	test-tool chmtime --get .git/index >out &&
> +	! grep ^1234567890 out