Symptom#

A test builds the same history twice, runs git in one repository and the tool under test in the other, and compares the results. It passes alone and fails now and then in a full, loaded test run:

• A commit template's Date: line differs by one second (22:02:07 vs 22:02:06).
• A stash message differs, because WIP on main: <sha> init names a HEAD id that differs.
• An assertion such as !log.contains("c0") fails because a random commit id contains c0 (cc0c50f).

Cause#

• A commit id and a displayed date depend on the author and committer time. The setup commits of the two repositories are made at the real time, and under load they fall in different seconds. Pinning dates only for the command under test does not help, because setup commits (the first commit, merge setups, the commit an --amend shows) still differ.
• A short substring such as a subject c0 also matches inside hexadecimal commit ids.

Fix#

• Make every commit in both repositories with fixed dates: set GIT_AUTHOR_DATE and GIT_COMMITTER_DATE (for example 2020-01-01T00:00:00Z) in the helper that makes the setup commits, not only for the command under test. Or rewrite the one commit a check shows with git commit --amend --no-edit --date=... (committer date via env too).
• Assert on whole tokens with their delimiters (",c1," in a table row, a full line), never on a short substring that can appear in an id.
• To find which case flakes, run the test binary alone in a loop, also with CPU load (yes > /dev/null &).

Evidence#

rgit, 2026-09-27/28: commit_dry_run_and_editor_template_match_git failed about once in three runs on the Date: line and was fixed by pinning the date of the commit the amend template shows; stash_push_takes_staged_pathspec_files_and_parts failed when the twin repos were built a second apart and was fixed by fixed dates in the repo helper's first commit (commit ec63f70); history_tools_take_ranges_paths_and_revisions failed about 1 run in 10 on contains("c0") and was fixed by matching ,c0,.