Re: [PATCH v4 04/15] scalar: 'register' sets recommended config and starts maintenance

[Elijah Newren <newren@gmail.com>]

On Tue, Sep 14, 2021 at 7:39 AM Derrick Stolee via GitGitGadget
<gitgitgadget@gmail.com> wrote:
...
> +static int set_recommended_config(void)
> +{
> +       struct {
> +               const char *key;
> +               const char *value;
> +       } config[] = {
> +               { "am.keepCR", "true" },
> +               { "core.FSCache", "true" },
> +               { "core.multiPackIndex", "true" },
> +               { "core.preloadIndex", "true" },
> +#ifndef WIN32
> +               { "core.untrackedCache", "true" },
> +#else
> +               /*
> +                * Unfortunately, Scalar's Functional Tests demonstrated
> +                * that the untracked cache feature is unreliable on Windows
> +                * (which is a bummer because that platform would benefit the
> +                * most from it). For some reason, freshly created files seem
> +                * not to update the directory's `lastModified` time
> +                * immediately, but the untracked cache would need to rely on
> +                * that.
> +                *
> +                * Therefore, with a sad heart, we disable this very useful
> +                * feature on Windows.
> +                */
> +               { "core.untrackedCache", "false" },
> +#endif

Interesting.  (I'm somewhat leery of the untrackedCache just knowing
that it used to operate despite an exponential number of visits to
files (exponential in depth of directories) and getting different
answers with different visits, making me feel like it was black magic
that it ever worked and wondering what kind of corner case issues
still lurk with it.  See e.g.
https://lore.kernel.org/git/CABPp-BFiwzzUgiTj_zu+vF5x20L0=1cf25cHwk7KZQj2YkVzXw@mail.gmail.com/)

> +               { "core.logAllRefUpdates", "true" },
> +               { "credential.https://dev.azure.com.useHttpPath", "true" },

Not only opinionated, but special configuration for certain sites?
I'm not complaining, just slightly surprised.

> +               { "credential.validate", "false" }, /* GCM4W-only */
> +               { "gc.auto", "0" },
> +               { "gui.GCWarning", "false" },
> +               { "index.threads", "true" },
> +               { "index.version", "4" },

I take it your users don't make use of jgit?  (Users aren't using jgit
directly here, at least not to my knowledge, but multiple gradle
plugins do.)  I tried turning this on a while back, and quickly got
multiple reports of problems because jgit didn't understand the index.
I had to turn it off and send out various PSAs on how to recover.

> +               { "merge.stat", "false" },
> +               { "merge.renames", "false" },

Is this just historical and not needed anymore, is it here just for a
little longer and you are planning on transitioning away from this, or
are you still set on this setting?

> +               { "pack.useBitmaps", "false" },

I don't understand anything bitmap related, but I thought they were
performance related, so I'm surprised by this one.  Is there a reason
for this one?  (Is it handled by maintenance instead?)

> +               { "pack.useSparse", "true" },
> +               { "receive.autoGC", "false" },
> +               { "reset.quiet", "true" },
> +               { "feature.manyFiles", "false" },

If you simply set core.untrackedCache to false _after_ setting
feature.manyFiles to true, would it make sense to switch this?  (Or
does it matter, since you've already individually set all the config
settings that this one would set?)

> +               { "feature.experimental", "false" },
> +               { "fetch.unpackLimit", "1" },
> +               { "fetch.writeCommitGraph", "false" },
> +#ifdef WIN32
> +               { "http.sslBackend", "schannel" },
> +#endif
> +               { "status.aheadBehind", "false" },
> +               { "commitGraph.generationVersion", "1" },
> +               { "core.autoCRLF", "false" },
> +               { "core.safeCRLF", "false" },
> +               { NULL, NULL },
> +       };

Are there easy-ish ways for other groups of users to adopt scalar but
change the list of config settings (e.g. index.version and
merge.renames) in some common way for all those users?