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

> On 12/11/2025 9:20 AM, Henrique Ferreiro wrote:
>> 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.
>   
>>> +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.

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