On Sat, Nov 05, 2022 at 11:45:32AM -0700, Ronan Pigott wrote:
> maintenance register currently records the maintenance repo exclusively
> within the user's global configuration, but other configuration files
> may be relevant when running maintenance if they are included from the
> global config. This option allows the user to choose where maintenance
> repos are recorded.
I see. So we don't change the location of the config that 'maintenance
run/start' are reading from, but we can change the location of the
config we use to record which repositories are maintenance candidates.
I guess it makes sense if you are including arbitrary configuration
files in your global config, so this seems reasonable to me.
> Signed-off-by: Ronan Pigott <ronan@xxxxxx>
> ---
>
> I track my global config in a bare gitrepo, and include host-specific
> configuration from an auxiliary path. Since on each host I may work on
> different repos, at different paths, and have different preferences for
> prefetch or gc frequency, I record maintenance repos in this
> host-specific config. This option will facilitate this use case.
>
> Documentation/git-maintenance.txt | 14 +++++++-------
> builtin/gc.c | 28 +++++++++++++++++-----------
> t/t7900-maintenance.sh | 15 +++++++++++++++
> 3 files changed, 39 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/git-maintenance.txt b/Documentation/git-maintenance.txt
> index bb888690e4..eb3ae9fbd5 100644
> --- a/Documentation/git-maintenance.txt
> +++ b/Documentation/git-maintenance.txt
> @@ -50,13 +50,13 @@ stop::
> the background maintenance is restarted later.
>
> register::
> - Initialize Git config values so any scheduled maintenance will
> - start running on this repository. This adds the repository to the
> - `maintenance.repo` config variable in the current user's global
> - config and enables some recommended configuration values for
> - `maintenance.<task>.schedule`. The tasks that are enabled are safe
> - for running in the background without disrupting foreground
> - processes.
> + Initialize Git config values so any scheduled maintenance will start
> + running on this repository. This adds the repository to the
> + `maintenance.repo` config variable in the current user's global config,
> + or the config specified by --config option, and enables some
> + recommended configuration values for `maintenance.<task>.schedule`. The
> + tasks that are enabled are safe for running in the background without
> + disrupting foreground processes.
The new text looks good, but there is some unnecessary line re-wrapping
that occurred around it.
> The `register` subcommand will also set the `maintenance.strategy` config
> value to `incremental`, if this value is not previously set. The
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 24ea85c7af..5da6905033 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -1454,13 +1454,15 @@ static char *get_maintpath(void)
> }
>
> static char const * const builtin_maintenance_register_usage[] = {
> - "git maintenance register",
> + "git maintenance register [--config <file>]",
"<path>" (instead of "<file>") is slightly more common these days.
> NULL
> };
>
> static int maintenance_register(int argc, const char **argv, const char *prefix)
> {
> + const char *config_file = NULL;
> struct option options[] = {
> + OPT_STRING('c', "config", &config_file, N_("file"), N_("use given config file")),
> OPT_END(),
> };
> int found = 0;
> @@ -1502,7 +1504,7 @@ static int maintenance_register(int argc, const char **argv, const char *prefix)
> if (!user_config)
> die(_("$HOME not set"));
Hmm. I wonder if we want to avoid calling git_global_config() when we
don't need to. Maybe something like this:
--- >8 ---
diff --git a/builtin/gc.c b/builtin/gc.c
index 5da6905033..13a2633912 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -1460,7 +1460,7 @@ static char const * const builtin_maintenance_register_usage[] = {
static int maintenance_register(int argc, const char **argv, const char *prefix)
{
- const char *config_file = NULL;
+ char *config_file = NULL;
struct option options[] = {
OPT_STRING('c', "config", &config_file, N_("file"), N_("use given config file")),
OPT_END(),
@@ -1499,14 +1499,21 @@ static int maintenance_register(int argc, const char **argv, const char *prefix)
if (!found) {
int rc;
- char *user_config, *xdg_config;
- git_global_config(&user_config, &xdg_config);
- if (!user_config)
- die(_("$HOME not set"));
+ char *user_config = NULL, *xdg_config = NULL;
+ char *to_free = NULL;
+
+ if (config_file) {
+ user_config = config_file;
+ } else {
+ git_global_config(&user_config, &xdg_config);
+ to_free = user_config;
+ if (!user_config)
+ die(_("$HOME not set"));
+ }
rc = git_config_set_multivar_in_file_gently(
- config_file ?: user_config, "maintenance.repo", maintpath,
+ user_config, "maintenance.repo", maintpath,
CONFIG_REGEX_NONE, 0);
- free(user_config);
+ free(to_free);
free(xdg_config);
if (rc)
--- 8< ---
> - user_config, key, NULL, maintpath,
> + config_file ?: user_config, key, NULL, maintpath,
Same note(s) here, too.
> @@ -500,6 +500,21 @@ test_expect_success 'register and unregister' '
> git config --global --get-all maintenance.repo >actual &&
> test_cmp before actual &&
>
> + git config --file ./other --add maintenance.repo /existing1 &&
> + git config --file ./other --add maintenance.repo /existing2 &&
> + git config --file ./other --get-all maintenance.repo >before &&
I was wondering why you didn't bother writing all of this into "expect",
and then appending "pwd" onto the end of it.
> + git maintenance register --config ./other &&
> + test_cmp_config false maintenance.auto &&
> + git config --file ./other --get-all maintenance.repo >between &&
> + cp before expect &&
> + pwd >>expect &&
> + test_cmp expect between &&
...since it would have simplified the setup here.
> + git maintenance unregister --config ./other &&
> + git config --file ./other --get-all maintenance.repo >actual &&
> + test_cmp before actual &&
...but here you want to compare the output you got above with everything
that was configured before, i.e., just what came out of the first three
lines. Makes sense.
Thanks,
Taylor
