On Tue, Apr 27 2021, Han-Wen Nienhuys via GitGitGadget wrote:
> From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
>
> Reftable automatically compacts tables on writes. The functionality of
> incremental compaction is unittested in reftable/stack_test.c
> (test_reftable_stack_auto_compaction)
>
> In addition, pack-refs triggers a full compaction of the entire stack. This is
> exercised in t0031-reftable.sh.
>
> Given that git-maintenance simply calls out git-pack-refs, it seems superfluous
> to test this further for reftable.
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
> ---
> t/t7900-maintenance.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
> index 2412d8c5c006..6f2f55a6c51d 100755
> --- a/t/t7900-maintenance.sh
> +++ b/t/t7900-maintenance.sh
> @@ -343,7 +343,7 @@ test_expect_success 'maintenance.incremental-repack.auto' '
> test_subcommand git multi-pack-index write --no-progress <trace-B
> '
>
> -test_expect_success 'pack-refs task' '
> +test_expect_success REFFILES 'pack-refs task' '
> for n in $(test_seq 1 5)
> do
> git branch -f to-pack/$n HEAD || return 1
I don't think it's superfluous to test what "git maintenance" does
anyway, i.e. the test ends with:
test_subcommand git pack-refs --all --prune
Shouldn't we test that we .. don't run that, abort, warn, whatever?
Anyway, as with another earlier comment of mine we're going to have
chicken & egg problems with amending these tests and then actually
introducing reftable support, so maybe "not yet", but I worry in general
about the loss of coverage...
