Re: [PATCH 1/2] maintenance: set log.excludeDecoration durin prefetch
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Jan 18, 2021, 15:57 UTC
- Message-ID
- <YAWv+5HDxEvBK+8R@nand.local>
- In-Reply-To
- <5b2ce9049a69d4c450093433e4fa15c4e5e0c412.1610940216.git.gitgitgadget@gmail.com>
Not related to the patch below, but in the subject line: s/durin/\0g/.
On Mon, Jan 18, 2021 at 03:23:35AM +0000, Derrick Stolee via GitGitGadget wrote:
Show 14 quoted lines
> diff --git a/builtin/gc.c b/builtin/gc.c
> index b315b2ad588..54bae7f0c4c 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -897,6 +897,12 @@ static int maintenance_task_prefetch(struct maintenance_run_opts *opts)
> struct string_list_item *item;
> struct string_list remotes = STRING_LIST_INIT_DUP;
>
> + git_config_set_multivar_gently("log.excludedecoration",
> + "refs/prefetch/",
> + "refs/prefetch/",
> + CONFIG_FLAGS_FIXED_VALUE |
> + CONFIG_FLAGS_MULTI_REPLACE);
> +OK; this is a good way to ensure that you're not constantly appending 'refs/prefetch' into the config.
I did notice that we have a 'remotes' string list just above, so I suppose we could only ignore 'refs/prefetch/<remote>' for just the remotes that we know about, but I doubt that this would be all that useful. (I.e., are there really users that are using refs/prefetch already and don't want to hide the parts of it that aren't managed by maintenance? Doubtful.)
Show 18 quoted lines
> +test_expect_success 'prefetch and existing log.excludeDecoration values' ' > + git config --unset-all log.excludeDecoration && > + git config log.excludeDecoration refs/remotes/remote1/ && > + git maintenance run --task=prefetch && > + > + git config --get-all log.excludeDecoration >out && > + grep refs/remotes/remote1/ out && > + grep refs/prefetch/ out && > + > + git log --oneline --decorate --all >log && > + ! grep "prefetch" log && > + ! grep "remote1" log && > + grep "remote2" log && > + > + # a second run does not change the config > + git maintenance run --task=prefetch && > + git log --oneline --decorate --all >log2 && > + test_cmp log log2
Great, this test matches what I would expect. Thank you!
Thanks, Taylor