On Tue, Apr 21, 2020 at 10:14 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > * what is a good test strategy? Could we have a CI flavor where we flip the > > default to reftable, and see how it fares? > > I do not know if the current tests are prepared for it yet, > e.g. there may be places that say "cat .git/refs/heads/master" and > do something to its contents. But I think that it is a good goal to > shoot for to make sure we can run all the tests with reftable > enabled. Obviously, it would be nice if all tests pass, but that doesn't seem very realistic. hanwen@chiquinho:~/vc/git/t$ grep '^ok' log | wc 18457 154017 896360 hanwen@chiquinho:~/vc/git/t$ grep '^not ok' log | wc 3416 39825 228427 I expect that the bulk of this number reflects a (hopefully) small number of bugs in the reftable glue, but there are many tests that do things that are just not compatible with a more abstract ref database. For example, not ok 10 - check rev-list # # echo $SHA >"$REAL/HEAD" && # test "$SHA" = "$(git rev-list HEAD)" # What is the right way to approach this? Should the test use git update-ref HEAD $SHA instead of writing to the loose ref? Or should we skip it in case of reftable? Similarly git update-ref $m $A && test $A = $(cat .git/$m) My suggestion to leave these tests as is, but skip them if they can't work for reftable. However, this needs a new primitive in the test library; what should that primitive look like? Maybe a function, eg. test_expect_succes_skip_reftable or similar? -- 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
