Re: [PATCH] MIDX: revert the default version to v1

[Taylor Blau <me@ttaylorr.com>]

On Thu, Apr 16, 2026 at 04:06:59PM -0400, Jeff King wrote:
> This looks fine to me, and you can add my S-o-b if you want. But let me
> propose a slight alternative that reduces the test churn and may make
> things easier going forward.

Same here, I agree with the discussion earlier in the thread about what
the right short- and medium-term solutions are, and I think that
including Junio's patch is a good approach.

If we take that, please also feel free to add my Acked-by, or
Reviewed-by, or similar.

> -- >8 --
> Subject: [PATCH] MIDX: revert the default version to v1
>
> We introduced midx version 2 in b2ec8e90c2 (midx: do not require packs
> to be sorted in lexicographic order, 2026-02-24) and now write it by
> default. The rationale was that older versions should ignore the v2 midx
> and fall back to using the packs (just like we do for other midx
> errors). Unfortunately this is not the case, as we have a hard die()
> when we see an unknown midx version.
>
> As a result, writing a midx with Git 2.54-rc2 puts the repository into a
> state that is unusable with Git 2.53. And this midx write may happen
> behind the scenes as part of normal operations, like fetch.

I'm not sure if it's worth mentioning, but I think that it's reasonable
to say "Git 2.53 and earlier", with the implied lower bound being which
version first introduced the MIDX. I think it's equally fine as-is,
though.

> Let's switch back to writing v1 by default to avoid regressing the case
> where multiple versions of Git are used on the same repository.
>
> There is one gotcha, though: the v2 format is required for some new
> features, like midx compaction, and running "git multi-pack-index
> compact" will complain when asked to write a v1 index. The user must set
> midx.version to "2" to make the feature work.
>
> So instead of always using v1, we'll base the default on whether the
> requested feature requires v2. That does mean that running midx
> compaction will create a repository that can't be read by older versions
> of Git. But we never do that by default; only people experimenting with
> the new feature will be affected.
>
> We have to adjust the test expectation in t5319, since it will now
> generate v1 files. And our "auto-select v2" is covered by the tests in
> t5335, which continue to check that compaction works without having to
> set midx.version manually (and also explicitly check that asking for v1
> with compaction reports the problem).

I think that the test fallout that Junio's patch necessitates isn't all
that bad, and in some sense I think the "write version 1 usually, but
version 2 if the feature requires it" is a little magical. That being
said, anyone doing things that would require a v2 MIDX likely already
understand what the trade-offs are, so in that sense I think that this
is less magical and more "do the sensible thing by default".

I don't have strong feelings either way and would be fine with either. I
think if anything I have a vague preference towards the approach taken
here, but either would be fine with me.

> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I have a feeling there are probably some gaps in v2 testing in t5319,
> since we are no longer using v2 for the bulk of the tests. IMHO that is
> OK to sort out post-release.

Perhaps, although you could make the opposite argument for v1 MIDXs
when we previously switched the default to write v2 MIDXs. The format
differs only in the version field, and the ordering constraints on the
packs within the MIDX. That area and the compatibility issues here are
the "interesting" parts to test IMHO.

>  Documentation/git-multi-pack-index.adoc | 3 +++
>  midx-write.c                            | 4 +++-
>  t/t5319-multi-pack-index.sh             | 2 +-
>  3 files changed, 7 insertions(+), 2 deletions(-)

The patch itself looks as expected to me. Thanks for working on it, and
sorry again for the mess here.

Thanks,
Taylor