Re: [PATCH 4/5] scalar: alphabetize and simplify config

From: Patrick Steinhardt <ps@pks.im>
Date: Dec 1, 2025, 08:55 UTC
Message-ID: <aS1YAugZpgtNkgkR@pks.im>
In-Reply-To: <9b8ce6ba2bcc802ae38b2e1223d7d93b03fb2a1b.1764195516.git.gitgitgadget@gmail.com>

On Wed, Nov 26, 2025 at 10:18:35PM +0000, Derrick Stolee via GitGitGadget wrote:

Show 13 quoted lines

> From: Derrick Stolee <stolee@gmail.com>
> 
> The config values set by Scalar went through an audit in the previous
> changes, so now reorganize the settings and simplify their purpose.
> 
> First, alphabetize the config options, except put the platform-specific
> options at the end. This groups two Windows-specific settings and only
> one non-Windows setting.
> 
> Also, this removes the 'overwrite_on_reconfigure' setting for many of
> these options. That setting made nearly all of these options "required"
> for scalar enlistments, restricting use for users. Instead, now nearly
> all options have removed this setting.

As far as I understand, this setting causes us to overwrite any preexisting config values when reconfiguring Scalar? So with your changes the effect is that we now don't do that anymore, which allows the user to tune some of the configuration values to their liking after having run `scalar init` for the first time. I guess that makes sense, as it gives the user more flexibility.

It does make me wonder though: is it really the most sensible thing to overwrite any keys that already exist in the configuration? We may end up overwriting configuration specified by the user both in the case of `scalar init` and `scalar reconfigure`. But arguably, we might want to only ever write configuration that does _not_ yet have an explicit value in the configuration file, regardless of whether or not we reconfigure.

Show 6 quoted lines

> However, there is one setting that still has this, which is
> index.skipHash, which was previously being set to _false_ when we
> actually prefer the value of true. Keep the overwrite here to help
> Scalar users upgrade to the new version. We may remove that overwrite in
> the future once we belive that most of the users who have the false
> value have upgraded to a version that overwrites that to 'true'.

Makes sense. This has likely been a bug, and we now want to rectify that bug.

Thanks!

Patrick