From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: MIDX woes, was Re: [ANNOUNCE] Git v2.54.0-rc2
Date: Thu, 16 Apr 2026 13:12:50 -0700 [thread overview]
Message-ID: <xmqqqzoezmt9.fsf@gitster.g> (raw)
In-Reply-To: <20260416194922.GA1887222@coredump.intra.peff.net> (Jeff King's message of "Thu, 16 Apr 2026 15:49:22 -0400")
Jeff King <peff@peff.net> writes:
> Yeah, I agree that re-wording would be a good idea here.
I actually no longer think so.
> I think this
> can happen post-release. We'd like for this to have happened long ago,
> but it didn't. Doing it in 2.54 versus 2.55 does not really matter, as:
>
> 1. We still have to worry about 2.53 and earlier anyway, so one
> version is not much in the grand scheme of things.
>
> 2. For midx v2, 2.54 knows how to read it anyway, so is not affected
> by the problem. ;)
I agree 100% with this.
Looking at the later part of load_multi_pack_index_one() function,
it is full of die() calls, not prepared to degrade gracefully at
all.
The reason why I do not think reword is worth doing is that as far
as this function (i.e., "Here is an MIDX file---please read it and
give me struct multi_pack_index back") is concerned, these error
returns are giving diagnosis on the nature of errors. Sometimes we
cannot learn the length of the file, sometimes we find that the file
is unreasonably short, sometimes it is not sorted properly, etc.
None of the existing "error + cleanup" says "we are continuing
anyway" and that is good. The decision to keep going without using
midx file (or not) belongs to the caller, so if we wanted to say
that, we should say so in the caller, not here.
next prev parent reply other threads:[~2026-04-16 20:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 15:22 [ANNOUNCE] Git v2.54.0-rc2 Junio C Hamano
2026-04-15 20:50 ` MIDX woes, was " Johannes Schindelin
2026-04-15 21:04 ` Junio C Hamano
2026-04-16 5:17 ` Jeff King
2026-04-16 5:34 ` Jeff King
2026-04-16 13:24 ` Derrick Stolee
2026-04-16 16:09 ` Junio C Hamano
2026-04-16 20:29 ` Taylor Blau
2026-04-19 22:41 ` Derrick Stolee
2026-04-20 1:52 ` Junio C Hamano
2026-04-16 20:26 ` Taylor Blau
2026-04-16 23:29 ` Jeff King
2026-04-16 18:10 ` Junio C Hamano
2026-04-16 18:18 ` Junio C Hamano
2026-04-16 19:49 ` Jeff King
2026-04-16 20:12 ` Junio C Hamano [this message]
2026-04-16 23:23 ` Jeff King
2026-04-17 4:15 ` Junio C Hamano
2026-04-16 18:45 ` [PATCH] MIDX: revert the default version to v1 Junio C Hamano
2026-04-16 19:38 ` Junio C Hamano
2026-04-16 20:58 ` Junio C Hamano
2026-04-16 21:13 ` Taylor Blau
2026-04-16 20:06 ` Jeff King
2026-04-16 20:55 ` Junio C Hamano
2026-04-16 23:24 ` Jeff King
2026-04-16 23:26 ` Jeff King
2026-04-16 21:12 ` Taylor Blau
2026-04-16 23:27 ` Jeff King
2026-04-17 15:19 ` [ANNOUNCE] Git v2.54.0-rc2 Junio C Hamano
2026-04-17 17:03 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqqzoezmt9.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox