From: Henrique Ferreiro Date: Mon, 15 Dec 2025 12:14:55 GMT Subject: Re: [PATCH v2 5/5] scalar: document config settings Message-ID: In-Reply-To: On 12/12/25 3:06 PM, Derrick Stolee wrote: > 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 >>> >>> 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? It appears you missed my question above. >>> +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. Given that this is just a possibility, and also that it only affects a subset of users, wouldn't it make more sense to instead check for those settings in the global config, and only if they are enabled override their value or just show a warning? >>> +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. OK. I'll do that, thanks! > Thanks, > -Stolee >