From: Derrick Stolee <stolee@gmail.com>
To: Taylor Blau <me@ttaylorr.com>,
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: Tue, 14 Apr 2020 11:10:33 -0400 [thread overview]
Message-ID: <0b9e3156-1101-0f19-91eb-36af541519aa@gmail.com> (raw)
In-Reply-To: <20200413154945.GA59601@syl.local>
On 4/13/2020 11:49 AM, Taylor Blau wrote:
> 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.
That seems like a good way to help users.
>> 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?
The reason is I forgot about it.
Thanks,
-Stolee
next prev parent reply other threads:[~2020-04-14 15:10 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
2020-04-14 15:10 ` Derrick Stolee [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b9e3156-1101-0f19-91eb-36af541519aa@gmail.com \
--to=stolee@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).