Re: [PATCH v2 5/5] scalar: document config settings

From: Derrick Stolee <stolee@gmail.com>
Date: Dec 12, 2025, 14:06 UTC
Message-ID: <e1d51a8f-582f-425e-9682-c93411b4d090@gmail.com>
In-Reply-To: <e19246a7-40db-41d0-9cdf-817833123f45@igalia.com>

On 12/11/2025 9:20 AM, Henrique Ferreiro wrote:

Show 19 quoted lines

> On 12/1/25 5:50 PM, Derrick Stolee via GitGitGadget wrote:
>> From: Derrick Stolee <stolee@gmail.com>
>>
>> Add user-facing documentation that justifies the values being set by
>> 'scalar clone', 'scalar register', and 'scalar reconfigure'.
> 
> Hi Derrick. I was planning to contribute a patch removing some config
> options so I'll take this opportunity to just discuss those here.
> 
> My motivation is that some of the options seem to be related to things
> other than performance and the list is huge, so I believe that some
> options don't belong to scalar.
> 
>> +REQUIRED AND RECOMMENDED CONFIG
>> +-------------------------------
> 
> There's no mention on which configs are required and which are
> recommended, and it looks like none are actually required so maybe just
> remove REQUIRED.

You're absolutely right. Good eye! I started this documentation before
going back and removing the "required" configs.

Show 13 quoted lines

>> +am.keepCR=true::
>> +core.logAllRefUpdates=true::
>> +credential.https://dev.azure.com.useHttpPath=true::
>> +http.sslBackend=schannel::
> 
> These options are not related to performance. Why not keeping them out
> of scalar?
> 
>> +core.autoCRLF=false::
>> +core.safeCRLF=false::
>> +index.threads=true::
> 
> These options just duplicate the default settings.

We did find that index.threads=true gives something more when explicitly set, so there is currently value in keeping it explicit.

The CRLF configs are sometimes set globally on Windows systems, but we
want the local repository to override those global settings for
performance reasons.

Show 12 quoted lines

>> +feature.manyFiles=false::
>> +    This disables the "many files" optimizations grouped under this feature
>> +    config. The expectation is that all valuable optimizations are also set
>> +    explicitly by Scalar config, and any differences are intentional.
> 
> I disagree with this reasoning. This thread was actually brought to my
> attention when working on setting manyFiles to true in scalar:
> https://github.com/git/git/pull/2125.
> 
> Do you foresee any features that would apply to scalar but not to
> manyFiles? I'd even say that some scalar options could be moved to
> manyFiles instead, so that people that don't use scalar can benefit too.

I suppose that the default reason is that registering a repo with Scalar already enables some config in an "indirect" way and having it rely on features.manyFiles would be another layer of indirection.

The historical reason is that we initially didn't want changes to the features.* config settings to automatically be assigned to Scalar. I think this is more important on the features.experimental side, as the intention of features.manyFiles is very similar to the intention of cloning/registering with Scalar.

For now, I'm going to leave this as-is, because we have enough changes to the config settings and documentation. You can submit a change on top of this one to demonstrate the value of setting features.manyFiles=true and how that impacts the code in its new shape.

Thanks, -Stolee