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@xxxxxxxxxxxxx> >> >> 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@xxxxxxxxx/ >> >> Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> --- >> 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
