Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> +test_expect_success 'drop stash reflog updates refs/stash' ' >> + git reset --hard && >> + git rev-parse refs/stash >expect && >> + echo 9 >file && >> + git stash && >> + git stash drop stash@{0} && >> + git rev-parse refs/stash >actual && >> + test_cmp expect actual >> +' > > This one will be portable to the reftable backend. > >> +test_expect_success 'drop stash reflog updates refs/stash with rewrite' ' > > But as I noted in <220222.86fsob88h7.gmgdl@xxxxxxxxxxxxxxxxxxx> (but it > was easy to miss) this test will need to depend on REFFILES. So just > changing this line to: > > test_expect_success REFFILES 'drop stash[...]' > >> + git reset --hard && >> + echo 9 >file && >> + git stash && >> + oid="$(git rev-parse stash@{0})" && >> + git stash drop stash@{1} && >> + cut -d" " -f1-2 .git/logs/refs/stash >actual && >> + cat >expect <<-EOF && >> + $(test_oid zero) $oid >> + EOF >> + test_cmp expect actual >> +' Why should this be tested with "cut" in the first place, though? If we start from stash@{0} = A stash@{1} = B stash@{2} = C and after saying "drop stash@{1}", what we need to check is that stash@{0} = A stash@{1} = C now holds, which can be done with "git rev-parse", and the fact that the ref-files backend happens to record both before-and-after object IDs is an irrelevant implementation detail, no? I am still puzzled.