On 12/1/25 3:55 AM, Patrick Steinhardt wrote:

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

quoted

diff --git a/Documentation/scalar.adoc b/Documentation/scalar.adoc
index f81b2832f8..b34af225e6 100644
--- a/Documentation/scalar.adoc
+++ b/Documentation/scalar.adoc

@@ -197,6 +197,164 @@ delete <enlistment>::
  	This subcommand lets you delete an existing Scalar enlistment from your
  	local file system, unregistering the repository.
  
+REQUIRED AND RECOMMENDED CONFIG
+-------------------------------
+
+As part of both `scalar clone` and `scalar register`, certain Git config
+values are set to optimize for large repositories or cross-platform support.
+These options are updated in new Git versions according to the best known
+advice for large repositories, and users can get the latest recommendations
+by running `scalar reconfigure [--all]`.
+
+This section lists justifications for the config values that are set in the
+latest version.
+
+am.keepCR=true::
+	This setting is important for cross-platform development across Windows
+	and non-Windows platforms and keeping carriage return (`\r`) characters
+	in certain workflows.
+
+commitGraph.changedPaths=true::
+	This setting helps the background maintenance steps that compute the
+	serialized commit-graph to also store changed-path Bloom filters. This
+	accelerates file history commands and allows users to automatically
+	benefit without running a foreground command.

Is this something we also want to promote to "default" eventually? The
downside of course is that maintenance takes a bit longer, but given
that it runs in the background anyway this shouldn't really impact our
users all that much.

I'm not sure, as this is a significant cost to the computation time. It will
impact foreground commands, as well. It increases the size of the file, too.

It's worth considering, but I don't think the answer is very simple.

quoted

+commitGraph.generationVersion=1::
+	While the preferred version is 2 for performance reasons, existing users
+	that had version 1 by default will need special care in upgrading to
+	version 2. This is likely to change in the future as the upgrade story
+	is solidifies.

Is that still the case? We _did_ have some bugs in the upgrade path in
the past, but I thought it got all sorted out by now?

This is very likely, but I haven't validated myself. I'd be interested to
double-check and update this setting in a later series. If we update to 2,
then this would be a good reason to overwrite the old config for a while.

[snip]

quoted

+fetch.unpackLimit=1::
+	This setting prevents Git from unpacking packfiles into loose objects
+	as they are downloaded from the server. This feature was intended as a
+	way to prevent performance issues from too many packfiles, but Scalar
+	uses background maintenance to group packfiles and cover them with a
+	multi-pack-index, removing this issue.

The second sentence here reads as if "fetch.unpackLimit=1" was the
feature you are talking about, which led to some puzzlement at first.
But what you are talking about is the _default_ unpack limit of 100.
Maybe something like this reads better?

     This setting prevents Git from unpacking packfiles into loose objects
     as they are downloaded from the server. The default limit of 100
     objects was intended as a way to prevent performance issues from too
     many packfiles, but Scalar uses background maintenance to group
     packfiles and cover them with a multi-pack-index, removing this
     issue.

Good catch. Thanks!

-Stolee