Re: [PATCH v4 11/15] scalar: allow reconfiguring an existing enlistment
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Oct 6, 2021, 20:43 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2110062241150.395@tvgsbejvaqbjf.bet>
- In-Reply-To
- <CABPp-BG3FwBVO67ZVPCLokA3xh5=fLiXYe-K2GiRa7ELFvQkEA@mail.gmail.com>
Hi Elijah,
On Mon, 27 Sep 2021, Elijah Newren wrote:
Show 99 quoted lines
> On Tue, Sep 14, 2021 at 7:39 AM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > This comes in handy during Scalar upgrades, or when config settings were
> > messed up by mistake.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > contrib/scalar/scalar.c | 79 +++++++++++++++++++++-----------
> > contrib/scalar/scalar.txt | 8 ++++
> > contrib/scalar/t/t9099-scalar.sh | 8 ++++
> > 3 files changed, 67 insertions(+), 28 deletions(-)
> >
> > diff --git a/contrib/scalar/scalar.c b/contrib/scalar/scalar.c
> > index 8a11f390251..1fff7eb7c12 100644
> > --- a/contrib/scalar/scalar.c
> > +++ b/contrib/scalar/scalar.c
> > @@ -115,18 +115,20 @@ static int run_git(const char *arg, ...)
> > return res;
> > }
> >
> > -static int set_recommended_config(void)
> > +static int set_recommended_config(int reconfigure)
> > {
> > struct {
> > const char *key;
> > const char *value;
> > + int overwrite_on_reconfigure;
> > } config[] = {
> > - { "am.keepCR", "true" },
> > - { "core.FSCache", "true" },
> > - { "core.multiPackIndex", "true" },
> > - { "core.preloadIndex", "true" },
> > + /* Required */
> > + { "am.keepCR", "true", 1 },
> > + { "core.FSCache", "true", 1 },
> > + { "core.multiPackIndex", "true", 1 },
> > + { "core.preloadIndex", "true", 1 },
> > #ifndef WIN32
> > - { "core.untrackedCache", "true" },
> > + { "core.untrackedCache", "true", 1 },
> > #else
> > /*
> > * Unfortunately, Scalar's Functional Tests demonstrated
> > @@ -140,28 +142,29 @@ static int set_recommended_config(void)
> > * Therefore, with a sad heart, we disable this very useful
> > * feature on Windows.
> > */
> > - { "core.untrackedCache", "false" },
> > + { "core.untrackedCache", "false", 1 },
> > #endif
> > - { "core.logAllRefUpdates", "true" },
> > - { "credential.https://dev.azure.com.useHttpPath", "true" },
> > - { "credential.validate", "false" }, /* GCM4W-only */
> > - { "gc.auto", "0" },
> > - { "gui.GCWarning", "false" },
> > - { "index.threads", "true" },
> > - { "index.version", "4" },
> > - { "merge.stat", "false" },
> > - { "merge.renames", "false" },
> > - { "pack.useBitmaps", "false" },
> > - { "pack.useSparse", "true" },
> > - { "receive.autoGC", "false" },
> > - { "reset.quiet", "true" },
> > - { "feature.manyFiles", "false" },
> > - { "feature.experimental", "false" },
> > - { "fetch.unpackLimit", "1" },
> > - { "fetch.writeCommitGraph", "false" },
> > + { "core.logAllRefUpdates", "true", 1 },
> > + { "credential.https://dev.azure.com.useHttpPath", "true", 1 },
> > + { "credential.validate", "false", 1 }, /* GCM4W-only */
> > + { "gc.auto", "0", 1 },
> > + { "gui.GCWarning", "false", 1 },
> > + { "index.threads", "true", 1 },
> > + { "index.version", "4", 1 },
> > + { "merge.stat", "false", 1 },
> > + { "merge.renames", "false", 1 },
> > + { "pack.useBitmaps", "false", 1 },
> > + { "pack.useSparse", "true", 1 },
> > + { "receive.autoGC", "false", 1 },
> > + { "reset.quiet", "true", 1 },
> > + { "feature.manyFiles", "false", 1 },
> > + { "feature.experimental", "false", 1 },
> > + { "fetch.unpackLimit", "1", 1 },
> > + { "fetch.writeCommitGraph", "false", 1 },
> > #ifdef WIN32
> > - { "http.sslBackend", "schannel" },
> > + { "http.sslBackend", "schannel", 1 },
> > #endif
> > + /* Optional */
> > { "status.aheadBehind", "false" },
> > { "commitGraph.generationVersion", "1" },
> > { "core.autoCRLF", "false" },
>
> Now you have optional settings...but index.version and merge.renames
> aren't among them?? Why are those required? (...and to go a step
> further; should merge.renames even be off in a merge-ort world?)I think the idea here is that they are required so that a `scalar reconfigure` will set them, even if the current enlistment had been created by a previous Scalar version that had _not_ set those.
And yes, in a merge-ort world, `merge.renames` should probably be forced to `true`, again because it is in the "Required" section.
Ciao, Dscho