Re: [PATCH v2 3/5] scalar: remove stale config values

From: Patrick Steinhardt <ps@pks.im>
Date: Dec 8, 2025, 06:58 UTC
Message-ID: <aTZ2_Y2FxbASYpPd@pks.im>
In-Reply-To: <xmqqms3vnn9e.fsf@gitster.g>

On Sun, Dec 07, 2025 at 09:34:05AM +0900, Junio C Hamano wrote:

Show 21 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > The logic around this was introduced in 2a9dedef2e (index: make
> > index.threads=true enable ieot and eoie, 2018-11-19), and the ultimate
> > reason for it seems to be backwards compatibility:
> >
> >     index.threads and index.recordOffsetTable unspecified: do not write
> >     the offset table yet (to avoid alarming the user with "ignoring IEOT
> >     extension" messages when an older version of Git accesses the
> >     repository) but do make use of multiple threads to read the index if
> >     the supporting offset table is present.
> >
> > Older versions of Git complained when they see unknown extensions, and
> > we didn't want to expose users to such warnings.
> 
> Not "Older versions".
> 
> Any version of Git should complain mandatory index extension that it
> does not understand.  And any version of Git, even today's Git,
> gives a note when it ignores an optional index extension it does not
> understand.

That's what I wanted to say, but I did so poorly :)

Show 14 quoted lines

> > That makes me wonder
> > whether it's time now to revisit that decision -- it's been 7 years
> > since then, I guess that many clients nowadays would understand the
> > extension. 
> 
> I do not think 7 years matters.  The only reason you might see the
> "ignoring" message is after using a newer version of Git that is
> aware of that index extension, and then reverting back to an older
> version.  As the index file is a purely local matter, it is not very
> likely situation to begin with, and when it happens, the user should
> be made aware of it.  Not understanding an optional index extension
> is not a breaking sin; but being in such a situation, i.e., the user
> is using older version of Git than they once used to use, is a note
> worthy vent.

Yeah, this is of course something that can happen. I'm a bit torn on the usefulness of the warning. Sure, it warns the user about something Git does not understand. But that's exactly why we have optional extensions in the first place: so that we can introduce something without old clients understanding it.

But I can also see arguments why we want to warn. The old client would always discard the information contained in the extension, and that may be unfortunate depending on the extension itself. Ultimately, it's only the user that can decide, but they are most likely not informed enough to judge whether the warning really should be ignored or not.

Maybe there should still be a configuration that allows us to disable this warning, for example via our advice infra?

> So yes, even this logic was introduced last week, if the only reason
> is to avoid showing the note, that design decision should be
> revisited.

I think the number of years it has been since the new extension was introduced does matter to a certain degree: the longer we wait, the less likely it is that users will have mixed versions of Git clients where one of the versions doesn't understand the extension.

Thanks!

Patrick