git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 4/4] scalar reconfigure: add --maintenance=<mode> option

From
Derrick Stolee <stolee@gmail.com>
Date
May 12, 2025, 14:34 UTC
Message-ID
<35ecaa1d-589f-4d28-9d97-78bae8de2d41@gmail.com>
In-Reply-To
<xmqqcyckayb4.fsf@gitster.g>
On 5/7/25 5:46 PM, Junio C Hamano wrote:
Show 21 quoted lines
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> Add a new --maintenance=<mode> option to 'scalar reconfigure' that
>> provides options for enabling (default), disabling, or leaving
>> background maintenance config as-is.
> 
> Hmph, this is a bit unexpected.
> 
>> +--maintenance=<mode>::
>> +	By default, Scalar configures the enlistment to use Git's
>> +	background maintenance feature; this is the same as using the
>> +	`--maintenance=enable` value for this option. Use the
>> +	`--maintenance=disable` to remove each considered enlistment
>> +	from background maintenance. Use `--maitnenance=keep' to leave
>> +	the background maintenance configuration untouched for These
>> +	repositories.
> 
> If I understand it correctly, here is the only place that the users
> can learn what the valid choices are, and it is not even an
> enumeration.  They are forced to read the entire paragraph to learn
> what the choices are.

I suppose this could be fixed by changing the `<mode>` to be of the form "[enable|disable|keep]".

Show 54 quoted lines
>> +		OPT_STRING(0, "maintenance", &maintenance_str,
>> +			 N_("<mode>"),
>> +			 N_("signal how to adjust background maintenance")),
> 
> And there is no hint what are the right <mode> strings are.
> 
>>   	const char * const usage[] = {
>> -		N_("scalar reconfigure [--all | <enlistment>]"),
>> +		N_("scalar reconfigure [--maintenance=<mode>] [--all | <enlistment>]"),
>>   		NULL
>>   	};
> 
> So "scalar reconfigure -h" would not tell readers what the right
> choices are, either.
> 
>> +	if (maintenance_str) {
>> +		if (!strcmp(maintenance_str, "enable"))
>> +			maintenance = 1;
>> +		else if (!strcmp(maintenance_str, "disable"))
>> +			maintenance = 0;
>> +		else if (!strcmp(maintenance_str, "keep"))
>> +			maintenance = -1;
>> +		else
>> +			die(_("unknown mode for --maintenance option: %s"),
>> +			    maintenance_str);
> 
> Those who say "scalar reconfigure --maintenance=yes" gets this
> message that tells 'yes' is not a known mode, without saying that
> they meant 'enable'.
> 
> The --opt=<mode> interface is good when we expect the vocabulary for
> <mode> to grow, but I am not sure if it is warranted in this case.
> Is there a strong reason why 'reconfigure' MUST enable the
> maintenance by default, even if it were originally disabled in the
> enlistment?  If there isn't, initializing maintenance to -1 and
> setting it with OPT_BOOL() would make the UI consistent with the
> register and clone subcommands, and also we can lose the above block
> to parse out a string.  Also the code below ...
> 
> 
>> @@ -758,7 +776,8 @@ static int cmd_reconfigure(int argc, const char **argv)
>>   		the_repository = old_repo;
>>   		repo_clear(&r);
>>   
>> -		if (toggle_maintenance(1) >= 0)
>> +		if (maintenance >= 0 &&
>> +		    toggle_maintenance(maintenance) >= 0)
>>   			succeeded = 1;
> 
> ... which does make perfect sense, would still be applicable.
> 
> I dunno.  I just feel that 3-way "mode" interface is too much hassle
> to get right (e.g., give hints to guide the users who forgot what
> modes are available and how they are spelled) for this code path.

My intention was to bend over backwards to prevent a behavior change in the default case. However, I'm coming around to understand that we don't need this background maintenance to be redone every time and can become a no-op by default. (Other new configuration will still happen.)

In the case where we're fine changing the default behavior, then the standard --[no-]maintenance option will work, though it is a three-way switch where the lack of its existence means "don't do either mode".

I've got a new version of this patch doing what you asked for in the first place.

Thanks, -Stolee

Previous: Junio C HamanoNext: Junio C Hamano
Message 24 of 30 in “scalar: add --no-maintenance option”
  1. 0/2 scalar: add --no-maintenance optionDerrick Stolee via GitGitGadget, Apr 30, 2025
  2. 1/2 scalar register: add --no-maintenance optionDerrick Stolee via GitGitGadget, Apr 30, 2025
  3. Patrick SteinhardtMay 2, 2025
  4. Derrick StoleeMay 2, 2025
  5. 2/2 scalar clone: add --no-maintenance optionDerrick Stolee via GitGitGadget, Apr 30, 2025
  6. Junio C HamanoApr 30, 2025
  7. Derrick StoleeMay 1, 2025
  8. Junio C HamanoMay 1, 2025
  9. Junio C HamanoMay 1, 2025
  10. 0/4 scalar: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 5, 2025
  11. 1/4 scalar: customize register_dir()'s behaviorDerrick Stolee via GitGitGadget, May 5, 2025
  12. 2/4 scalar register: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 5, 2025
  13. 3/4 scalar clone: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 5, 2025
  14. 4/4 scalar reconfigure: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 5, 2025
  15. Junio C HamanoMay 5, 2025
  16. Derrick StoleeMay 6, 2025
  17. Junio C HamanoMay 6, 2025
  18. 0/4 scalar: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 7, 2025
  19. 1/4 scalar: customize register_dir()'s behaviorDerrick Stolee via GitGitGadget, May 7, 2025
  20. 2/4 scalar register: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 7, 2025
  21. 3/4 scalar clone: add --no-maintenance optionDerrick Stolee via GitGitGadget, May 7, 2025
  22. 4/4 scalar reconfigure: add --maintenance=<mode> optionDerrick Stolee via GitGitGadget, May 7, 2025
  23. Junio C HamanoMay 7, 2025
  24. Derrick StoleeMay 12, 2025
  25. Junio C HamanoMay 12, 2025
  26. Derrick StoleeMay 12, 2025
  27. Junio C HamanoMay 14, 2025
  28. 5/4 scalar reconfigure: improve --maintenance docsDerrick Stolee, May 14, 2025
  29. Junio C HamanoMay 14, 2025
  30. Derrick StoleeMay 16, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.