All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, sluongng@gmail.com,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] log: add log.excludeDecoration config option
Date: Mon, 13 Apr 2020 09:49:45 -0600	[thread overview]
Message-ID: <20200413154945.GA59601@syl.local> (raw)
In-Reply-To: <pull.610.git.1586791720114.gitgitgadget@gmail.com>

Hi Stolee,

On Mon, Apr 13, 2020 at 03:28:39PM +0000, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <dstolee@microsoft.com>
>
> In 'git log', the --decorate-refs-exclude option appends a pattern
> to a string_list. This list is used to prevent showing some refs
> in the decoration output, or even by --simplify-by-decoration.
>
> Users may want to use their refs space to store utility refs that
> should not appear in the decoration output. For example, Scalar [1]
> runs a background fetch but places the "new" refs inside the
> refs/scalar/hidden/<remote>/* refspace instead of refs/<remote>/*
> to avoid updating remote refs when the user is not looking. However,
> these "hidden" refs appear during regular 'git log' queries.
>
> A similar idea to use "hidden" refs is under consideration for core
> Git [2].
>
> Add the 'log.excludeDecoration' config option so users can exclude
> some refs from decorations by default instead of needing to use
> --decorate-refs-exclude manually. The config value is multi-valued
> much like the command-line option.
>
> There are several tests in t4202-log.sh that test the
> --decorate-refs-(include|exclude) options, so these are extended.
> Since the expected output is already stored as a file, simply add
> new calls that replace a "--decorate-refs-exclude" option with an
> in-line config setting.
>
> [1] https://github.com/microsoft/scalar
> [2] https://lore.kernel.org/git/77b1da5d3063a2404cd750adfe3bb8be9b6c497d.1585946894.git.gitgitgadget@gmail.com/
>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> ---
>     log: add log.excludeDecoration config option
>
>     This was something hinted at in the "fetch" step of the background
>     maintenance RFC. Should be a relatively minor addition to our config
>     options.
>
>     We definitely want this feature for microsoft/git (we would set
>     log.excludeDecoration=refs/scalar/* in all Scalar repos), but we will
>     wait for feedback from the community.
>
>     Thanks, -Stolee
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-610%2Fderrickstolee%2Flog-exclude-decoration-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-610/derrickstolee/log-exclude-decoration-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/610
>
>  Documentation/config/log.txt |  5 +++++
>  builtin/log.c                | 14 ++++++++++++++
>  t/t4202-log.sh               | 22 ++++++++++++++++++++++
>  3 files changed, 41 insertions(+)
>
> diff --git a/Documentation/config/log.txt b/Documentation/config/log.txt
> index e9e1e397f3f..1a158324f79 100644
> --- a/Documentation/config/log.txt
> +++ b/Documentation/config/log.txt
> @@ -18,6 +18,11 @@ log.decorate::
>  	names are shown. This is the same as the `--decorate` option
>  	of the `git log`.
>
> +log.excludeDecoration::
> +	Exclude the specified patterns from the log decorations. This multi-
> +	valued config option is the same as the `--decorate-refs-exclude`
> +	option of `git log`.
> +

Thanks for this documentation update. Do you think that it would be
worth updating the entry for '--decorate-refs-exclude', too? I figure
that it would be good, since scripters who look at 'git log's man page
before 'git config's would have a trail to follow in case they want a
persistent '--decorate-refs-exclude' option.

>  log.follow::
>  	If `true`, `git log` will act as if the `--follow` option was used when
>  	a single <path> is given.  This has the same limitations as `--follow`,
> diff --git a/builtin/log.c b/builtin/log.c
> index 83a4a6188e2..d7d1d5b7143 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -236,7 +236,21 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
>  	}
>
>  	if (decoration_style) {
> +		const struct string_list *config_exclude =
> +			repo_config_get_value_multi(the_repository,
> +						    "log.excludeDecoration");
> +
> +		if (config_exclude) {
> +			struct string_list_item *item;
> +			for (item = config_exclude->items;
> +			     item && item < config_exclude->items + config_exclude->nr;
> +			     item++)

Any reason not to use the 'for_each_string_list_item' macro in
'string-list.h' for this?

> +				string_list_append(&decorate_refs_exclude,
> +						item->string);
> +		}
> +

On my first read, I thought that there might be some value in using a
hash set here, since I (incorrectly) thought that only literal reference
names were added here, in which case we'd benefit from a constant time
lookup.

But, since we store patterns here, it's not helpful for us to have a
constant time lookup, since we don't have anything to look up in the
first place! I guess you could expand out all of these patterns ahead of
time, but I don't think that this is universally a good thing to do. We
may have a pattern like 'refs/heads/*', but we're only doing a 'git log'
over a part of history that doesn't have many/any refs pointing at it,
in which case expanding ahead of time was a bad thing to do.

Of course, 'string_list_append' is going to potentially introduce
duplicate patterns, but I don't think that should be a huge problem,
since 'ref_filter_match' stops as soon as it finds an exclude/include. I
guess you could use 'string_list_insert', but it makes insertions more
expensive without a clear benefit.

>  		rev->show_decorations = 1;
> +
>  		load_ref_decorations(&decoration_filter, decoration_style);
>  	}
>
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 0f766ba65f5..b5de449e510 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -787,6 +787,9 @@ test_expect_success 'decorate-refs-exclude with glob' '
>  	EOF
>  	git log -n6 --decorate=short --pretty="tformat:%f%d" \
>  		--decorate-refs-exclude="heads/octopus*" >actual &&
> +	test_cmp expect.decorate actual &&
> +	git -c log.excludeDecoration="heads/octopus*" log \
> +		-n6 --decorate=short --pretty="tformat:%f%d" >actual &&
>  	test_cmp expect.decorate actual
>  '
>
> @@ -801,6 +804,9 @@ test_expect_success 'decorate-refs-exclude without globs' '
>  	EOF
>  	git log -n6 --decorate=short --pretty="tformat:%f%d" \
>  		--decorate-refs-exclude="tags/reach" >actual &&
> +	test_cmp expect.decorate actual &&
> +	git -c log.excludeDecoration="tags/reach" log \
> +		-n6 --decorate=short --pretty="tformat:%f%d" >actual &&
>  	test_cmp expect.decorate actual
>  '
>
> @@ -816,6 +822,14 @@ test_expect_success 'multiple decorate-refs-exclude' '
>  	git log -n6 --decorate=short --pretty="tformat:%f%d" \
>  		--decorate-refs-exclude="heads/octopus*" \
>  		--decorate-refs-exclude="tags/reach" >actual &&
> +	test_cmp expect.decorate actual &&
> +	git -c log.excludeDecoration="heads/octopus*" \
> +		-c log.excludeDecoration="tags/reach" log \
> +		-n6 --decorate=short --pretty="tformat:%f%d" >actual &&
> +	test_cmp expect.decorate actual &&
> +	git -c log.excludeDecoration="heads/octopus*" log \
> +		--decorate-refs-exclude="tags/reach" \
> +		-n6 --decorate=short --pretty="tformat:%f%d" >actual &&
>  	test_cmp expect.decorate actual
>  '
>
> @@ -831,6 +845,10 @@ test_expect_success 'decorate-refs and decorate-refs-exclude' '
>  	git log -n6 --decorate=short --pretty="tformat:%f%d" \
>  		--decorate-refs="heads/*" \
>  		--decorate-refs-exclude="heads/oc*" >actual &&
> +	test_cmp expect.decorate actual &&
> +	git -c log.excludeDecoration="heads/oc*" log \
> +		--decorate-refs="heads/*" \
> +		-n6 --decorate=short --pretty="tformat:%f%d" >actual &&
>  	test_cmp expect.decorate actual
>  '
>
> @@ -846,6 +864,10 @@ test_expect_success 'decorate-refs-exclude and simplify-by-decoration' '
>  	git log -n6 --decorate=short --pretty="tformat:%f%d" \
>  		--decorate-refs-exclude="*octopus*" \
>  		--simplify-by-decoration >actual &&
> +	test_cmp expect.decorate actual &&
> +	git -c log.excludeDecoration="*octopus*" log \
> +		-n6 --decorate=short --pretty="tformat:%f%d" \
> +		--simplify-by-decoration >actual &&
>  	test_cmp expect.decorate actual
>  '
>

Thanks for the tests, they look good. I like your strategy of repeating
the test with and without the new config settings.

>
> base-commit: 274b9cc25322d9ee79aa8e6d4e86f0ffe5ced925
> --
> gitgitgadget

Thanks,
Taylor

  reply	other threads:[~2020-04-13 15:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 15:28 [PATCH] log: add log.excludeDecoration config option Derrick Stolee via GitGitGadget
2020-04-13 15:49 ` Taylor Blau [this message]
2020-04-14 15:10   ` Derrick Stolee
2020-04-14 15:45     ` Taylor Blau
2020-04-14 16:00       ` Derrick Stolee
2020-04-14 17:19 ` Junio C Hamano
2020-04-14 17:49   ` Derrick Stolee
2020-04-14 18:10     ` Junio C Hamano
2020-04-15 14:14       ` Derrick Stolee
2020-04-15 15:44 ` [PATCH v2] " Derrick Stolee via GitGitGadget
2020-04-15 16:52   ` Taylor Blau
2020-04-15 17:24   ` Junio C Hamano
2020-04-15 17:29     ` Junio C Hamano
2020-04-16 12:36       ` Derrick Stolee
2020-04-16 12:46     ` Derrick Stolee
2020-04-16 14:15   ` [PATCH v3 0/2] " Derrick Stolee via GitGitGadget
2020-04-16 14:15     ` [PATCH v3 1/2] log-tree: make ref_filter_match() a helper method Derrick Stolee via GitGitGadget
2020-04-16 14:15     ` [PATCH v3 2/2] log: add log.excludeDecoration config option Derrick Stolee via GitGitGadget
2020-04-16 17:49       ` Junio C Hamano
2020-04-16 18:03         ` Junio C Hamano
2020-04-17  1:53           ` Derrick Stolee
2020-04-17  2:01             ` Junio C Hamano

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=20200413154945.GA59601@syl.local \
    --to=me@ttaylorr.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=sluongng@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.