On Tue, Jul 7, 2020 at 9:50 PM Junio C Hamano [off-list ref] wrote:
"Han-Wen Nienhuys via GitGitGadget" [off-list ref] writes:
quoted
From: Han-Wen Nienhuys <redacted>
Adds test_tick to t5801-remote-helpers.sh and t3203-branch-output.sh
That can be read from the patch. Also the subject tells us a half
of what you want to achieve with this change (by the way, your
subject is malformatted and lacks the <area>: prefix; perhaps
"[PATCH] tests: make commit object names reproducible" or something),
but the readers are left hanging without knowing what motivated the
change. Do any test pieces in these scripts change their behaviour
based on what exact object names are assigned to them, making them
flaky and hard to test, and if so which one and in what way?
You're right, I forgot to provide a piece of the puzzle. These tests
have been failing either legitimately or flakily with reftable.
I built a GIT_DEBUG_REFS functionality, which dumps ref backend
interactions onto stderr. This should be reworked to use the tracing
functionality, but you can look at the patch in my reftable series.
When a test fails with reftable, the easiest way to debug is running
it both with and without GIT_DEBUG_REFS=1, and running a diff on the
output.
This needs the commit SHA1s to be deterministic, or the SHA1s will
generate spurious diffs.
I agree with Jeff, that a more structural approach to making sha1s
deterministic would be preferable.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado