Hi Junio & Han-Wen, On Thu, 23 Apr 2020, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > > > >> 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? > > > > Preferred. > > > > I didn't bother checking the context, but if the test is checking > > "the history leading to $SHA has only one commit, i.e. $SHA, and > > rev-list can handle that correctly", certainly that would be a > > preferred rewrite, rather than skipping the check for reftable, > > which may risk not noticing that HEAD is broken with reftable. > > Now I have. The test is about various low-level machineries we have > work correctly even if .git is *not* a directory but is a "gitfile: > $other location" (which is an underlying mechanism for multiple > worktree support etc.), and it is making sure "git rev-list" > understands HEAD in such a repository that uses the gitfile mechanism. > > If I didn't know it, I might have said that "if we are interested in > seeing $SHA is a root commit, we should check it more directly, > perhaps by making sure 'cat-file commit $SHA' does not say 'parent' > and that won't need to write to .git/HEAD at all", but the point of > the test is to ensure 'rev-list' works correctly in such a > repository, I think "update-ref HEAD $SHA" would be the right "fix" > for the test. I believe the common strategy for this kind of thing is to - introduce a `GIT_TEST_*` variable that is used to change the default (follow e.g. GIT_TEST_COMMIT_GRAPH as an example) - either add a prereq that guards the test cases that cannot handle that knob (!REFTABLE in this case), or follow GIT_TEST_COMMIT_GRAPH's example again and _force_ its value to 0 for those test cases. Ciao, Dscho
