On Tue, Jul 7, 2020 at 9:50 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx> > > > > 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
