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

Adrian Ratiu [off-list ref] writes:

On Fri, 05 Dec 2025, Patrick Steinhardt [off-list ref] wrote:

quoted

On Wed, Nov 19, 2025 at 11:10:30PM +0200, Adrian Ratiu wrote:

quoted

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.

On Sat, Dec 06, 2025 at 07:52:13AM +0900, Junio C Hamano wrote:

Adrian Ratiu [off-list ref] writes:

quoted

On Fri, 05 Dec 2025, Patrick Steinhardt [off-list ref] wrote:

quoted

On Wed, Nov 19, 2025 at 11:10:30PM +0200, Adrian Ratiu wrote:

quoted

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.

I guess you could kind of have both: make it a runtime configuration
key, but have its default depend on a build configuration. You could for
example auto-enable it in case `WITH_BREAKING_CHANGES` is enabled. But I
myself am not sure whether the latter would really be all that important
in the first place.

Patrick

On Sat, 06 Dec 2025, Patrick Steinhardt [off-list ref] wrote:

On Sat, Dec 06, 2025 at 07:52:13AM +0900, Junio C Hamano wrote:

quoted

Adrian Ratiu [off-list ref] writes:

quoted

On Fri, 05 Dec 2025, Patrick Steinhardt [off-list ref] wrote:

quoted

On Wed, Nov 19, 2025 at 11:10:30PM +0200, Adrian Ratiu wrote:

quoted

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.

I guess you could kind of have both: make it a runtime configuration
key, but have its default depend on a build configuration. You could for
example auto-enable it in case `WITH_BREAKING_CHANGES` is enabled. But I
myself am not sure whether the latter would really be all that important
in the first place.

I'll have to revisit this after I implement the migration command design
you suggested for v6, to figure out exactly how to best implement this.

Thank you for this suggestion as well, likely I'll do something very
similar if it ends up being necessary.

On Sat, 06 Dec 2025, Junio C Hamano [off-list ref] wrote:

Adrian Ratiu [off-list ref] writes:

quoted

On Fri, 05 Dec 2025, Patrick Steinhardt [off-list ref] wrote:

quoted

On Wed, Nov 19, 2025 at 11:10:30PM +0200, Adrian Ratiu wrote:

quoted

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.