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

From: Patrick Steinhardt <ps@pks.im>
Date: Dec 2, 2025, 19:22 UTC
Message-ID: <aS88bnmZXMZCV5oS@pks.im>
In-Reply-To: <zbmzxqckpmf3h2sc7g3zvrhcyur2kmanv5uz6nyd2lgmi2it3b@i65jeyvcvqqy>

On Tue, Dec 02, 2025 at 07:04:24PM +0000, Matthew Hughes wrote:

Show 12 quoted lines

> On Tue, Dec 02, 2025 at 08:53:45AM +0100, Patrick Steinhardt wrote:
> > Wait. Are you saying that "index.recordOffsetTable" behaves differently
> > based on whether "index.threads" is implicitly enabled due to the
> > default value or explicitly enabled via the configuration?
> 
> That was my understanding from a cursory read of the results of searching for
> 'index.threads' in git-config:
> 
> > index.recordEndOfIndexEntries
> > ...
> > Defaults to true if index.threads has been explicitly enabled, false
> > otherwise

Hm, true. At least that's a concious decision then.

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. 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.

The only (documented) downside should thus not be that important anymore, but the upside is that reading the index would be faster if we default-enable writing the extension.

Patrick