Re: [PATCH v5 7/7] meson/Makefile: allow setting submodule encoding at build time

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Dec 8, 2025, 09:42 UTC
Message-ID: <87ldjdux6p.fsf@collabora.com>
In-Reply-To: <xmqqms3w7d9e.fsf@gitster.g>

On Sat, 06 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>
>> On Fri, 05 Dec 2025, Patrick Steinhardt <ps@pks.im> wrote:
>>> On Wed, Nov 19, 2025 at 11:10:30PM +0200, Adrian Ratiu wrote:
>>>> Some users find it difficult to distribute repo config changes for
>>>> enabling extensions.submoduleEncoding, or to enable it by passing
>>>> the config via cmdline, so we add a build-time option which can
>>>> enable the extension for convenience.
>>>
>>> Wouldn't it be more sensible to make this a runtime configuration key
>>> that users can configure in their gitconfig?
>>
>> The request I got from a combination of feedback from Junio, Aaron and
>> Josh is to avoid any kind of required user intervention or manual
>> migration, to find ways to automate the transition as much as possible.
>
> How would that lead to build-time behaviour change, though?
>
> Users in managed environments like $CORP can rely on /etc/gitconfig
> or equivalents managed by their corp-eng, so I am having a hard time
> imagining why we need anything more than an configuration variable
> looked at runtime.

Please see Josh's message:

https://public-inbox.org/git/20250816213642.3517822-1-adrian.ratiu@collabora.com/T/#m7d0d75126c81bef7d3619e53da6fa0cd69426570

A config variable looked up at runtime would solve most cases highlighted there, except for the force-enable `extensions.submoduleEncoding` regardless of the local config.

That is why I added this option :) though we do not have a local config in v5 because I saw no reason for it at the time.

For v6 I will likely implement Patrick's suggestion to introduce a config variable and just set its default at build-time which seems like the cleanest way to do it (and automatically run the v6 migration command instead of the current automatic fallback).

That would allow a smooth automatic transition which will address Josh's requirements.