From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, johannes.schindelin@gmx.de,
Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH 0/2] scalar: add --no-maintenance option
Date: Wed, 30 Apr 2025 13:28:03 -0700 [thread overview]
Message-ID: <xmqq8qnh1jjg.fsf@gitster.g> (raw)
In-Reply-To: <pull.1913.git.1746008680.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Wed, 30 Apr 2025 10:24:38 +0000")
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> These patches add a new --no-maintenance option to the scalar register and
> scalar clone commands. My motivation is based on setting up Scalar clones in
> automated environments that set up a repo onto a disk image for use later.
> If background maintenance runs during later setup steps, then this
> introduces a variable that is unexpected at minimum and disruptive at worst.
> The disruption comes in if the automation has steps to run git maintenance
> run --task=<X> commands but those commands are blocked due to the
> maintenance.lock file.
>
> Functionally, these leave the default behavior as-is but allow disabling the
> git maintenance start step when users opt-in to this difference. The idea of
> Scalar is to recommend the best practices for a typical user, but allowing
> customization for expert users.
The feature itself I do not have any objections to and I found the
reasoning given above very sound.
With these two patches, we still have an unconditional call to
toggle_maintenance(1) in cmd_reconfigure(). Shoudln't the call be
at least removed, which would mean that reconfiguring would not
change the auto-maintenance states, or made controllable from the
command line of "maintenance reconfigure"?
It somehow looks to me that the real culprit of making the result of
applying two patches still unsatisfactory is the original design to
have the toggle_maintenance() call made from inside register_dir()
in the first place. Shouldn't a much higher layer entry points like
cmd_register() and cmd_clone() be where the decision is made if
maintenance task should be set up (or not set up) by calling
toggle_maintenance(), leaving the register_dir() responsible only
for "enlist the directory to the system"?
IOW it feels to me that enabling (and now optionally disabling)
maintenance is tied too deeply into the act of enlisting a
directory; if we need to disable maintenance (and a mode to add
enlistment without enabling maintenance), it is a sign that it
shouldn't be a parameter into the register_dir() function that
controls what register_dir() does, and rather it should be done by
letting the caller who calls register_dir() decide to call (or not)
toggle_maintenance().
Thanks.
next prev parent reply other threads:[~2025-04-30 20:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 10:24 [PATCH 0/2] scalar: add --no-maintenance option Derrick Stolee via GitGitGadget
2025-04-30 10:24 ` [PATCH 1/2] scalar register: " Derrick Stolee via GitGitGadget
2025-05-02 9:15 ` Patrick Steinhardt
2025-05-02 15:01 ` Derrick Stolee
2025-04-30 10:24 ` [PATCH 2/2] scalar clone: " Derrick Stolee via GitGitGadget
2025-04-30 20:28 ` Junio C Hamano [this message]
2025-05-01 13:21 ` [PATCH 0/2] scalar: " Derrick Stolee
2025-05-01 16:38 ` Junio C Hamano
2025-05-01 18:20 ` Junio C Hamano
2025-05-05 15:27 ` [PATCH v2 0/4] " Derrick Stolee via GitGitGadget
2025-05-05 15:27 ` [PATCH v2 1/4] scalar: customize register_dir()'s behavior Derrick Stolee via GitGitGadget
2025-05-05 15:27 ` [PATCH v2 2/4] scalar register: add --no-maintenance option Derrick Stolee via GitGitGadget
2025-05-05 15:27 ` [PATCH v2 3/4] scalar clone: " Derrick Stolee via GitGitGadget
2025-05-05 15:27 ` [PATCH v2 4/4] scalar reconfigure: " Derrick Stolee via GitGitGadget
2025-05-05 21:47 ` Junio C Hamano
2025-05-06 18:00 ` Derrick Stolee
2025-05-06 22:16 ` Junio C Hamano
2025-05-07 1:50 ` [PATCH v3 0/4] scalar: " Derrick Stolee via GitGitGadget
2025-05-07 1:50 ` [PATCH v3 1/4] scalar: customize register_dir()'s behavior Derrick Stolee via GitGitGadget
2025-05-07 1:50 ` [PATCH v3 2/4] scalar register: add --no-maintenance option Derrick Stolee via GitGitGadget
2025-05-07 1:50 ` [PATCH v3 3/4] scalar clone: " Derrick Stolee via GitGitGadget
2025-05-07 1:50 ` [PATCH v3 4/4] scalar reconfigure: add --maintenance=<mode> option Derrick Stolee via GitGitGadget
2025-05-07 21:46 ` Junio C Hamano
2025-05-12 14:34 ` Derrick Stolee
2025-05-12 17:44 ` Junio C Hamano
2025-05-12 18:02 ` Derrick Stolee
2025-05-14 12:28 ` Junio C Hamano
2025-05-14 13:52 ` [PATCH 5/4] scalar reconfigure: improve --maintenance docs Derrick Stolee
2025-05-14 22:16 ` Junio C Hamano
2025-05-16 16:36 ` Derrick Stolee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq8qnh1jjg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).