Re: MIDX woes, was Re: [ANNOUNCE] Git v2.54.0-rc2

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>>  * Further work on incremental repacking using MIDX/bitmap
>
> I just noticed that a fetch with v2.54.0-rc2 into an existing repository
> rendered it unusable for Git v2.53.0:
>
>   fatal: multi-pack-index version 2 not recognized
>
> Is it possible that v2.54.0-rc2 forcefully uses a MIDX version that has
> _just_ been introduced?
>
> If so, that might have been a premature bump of the default MIDX version,
> if even the preceding Git version fails to handle that MIDX version. It is
> guaranteed to cause substantial problems in setups where e.g. libgit2 or
> JGit is expected to be used interchangeably with Git. It also causes
> problems when users have to downgrade Git, or use several Git versions
> side by side (e.g. using GitHub Desktop, which bundles its own version of
> Git).

Is b2ec8e90 (midx: do not require packs to be sorted in
lexicographic order, 2026-02-24), which says

    This change produces MIDXs which may not be correctly read with external
    tools or older versions of Git. Though older versions of Git know how to
    gracefully degrade and ignore any MIDX(s) they consider corrupt,
    external tools may not be as robust. To avoid unintentionally breaking
    any such tools, guard this change behind a version bump in the MIDX's
    on-disk format.
    
relevant?  The version bump seems to be doing more harm to "older
versions of Git" that "know how to gracefully degrade" by not
allowing them to degrade.

Taylor, perhaps you would want to add some instructions on how to
recover?  Like "rm -f .git/objects/pack/*.midx" or something?

Thanks, all.