Re: [PATCH v2 2/3] fsck: verify multi-pack-index when implictly enabled

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Sep 29, 2021, 06:20 UTC
Message-ID: <ebe894b4-af25-f79e-c43f-1839e075908d@sunshineco.com>
In-Reply-To: <20210917225459.68086-3-chooglen@google.com>

On 9/17/21 6:54 PM, Glen Choo wrote:

Show 22 quoted lines

> Like the previous commit, the_repository->settings.core_multi_pack_index
> is preferable to reading "core.multiPackIndex" from the config because
> prepare_repo_settings() sets a default value for
> the_repository->settings. This worked fine until core.multiPackIndex was
> enabled by default in 18e449f86b (midx: enable core.multiPackIndex by
> default, 2020-09-25).
> 
> Replace git_config_get_bool("core.multiPackIndex") in fsck with the
> equivalent call to the_repository->settings.multi_pack_index.
> 
> Signed-off-by: Glen Choo <chooglen@google.com>
> ---
> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
> @@ -407,7 +407,9 @@ test_expect_success 'verify incorrect offset' '
>   test_expect_success 'git-fsck incorrect offset' '
>   	corrupt_midx_and_verify $MIDX_BYTE_OFFSET "\377" $objdir \
>   		"incorrect object offset" \
> -		"git -c core.multipackindex=true fsck"
> +		"git -c core.multipackindex=true fsck" &&
> +		test_must_fail git fsck &&
> +		git -c core.multipackindex=false fsck
>   '

I guess the newly-added `test_must_fail git fsck` line is checking the fallback case then `core.multipackindex` is not set. We could make this check a bit more robust by _ensuring_ that it is unset rather than relying upon whatever state the configuration is in by the time this test is reached. Perhaps something like this:

     ...
     "git -c core.multipackindex=true fsck" &&
     test_unconfig core.multipackindex &&
     test_must_fail git fsck &&
     git -c core.multipackindex=false fsck

The indentation is a bit unusual. It aligns nicely and is, in some sense, easy to read, but the two new lines are over-indented considering that they are siblings of the corrupt_midx_and_verify() call.

Don't know if any of this is worth a re-roll, though.