git/t/t4013, branch master

t4013: switch default branch name to main

2025-09-10T20:34:59Z

Remove one of the last remaining uses of "TEST_GIT_DEFAULT_INITIAL_BRANCH= main" in the test suite. We have been steadily be converting tests from using "master" as the default branch name since the introduction of TEST_GIT_DEFAULT_INITIAL_BRANCH in 704fed9ea22 (tests: start moving to a different default main branch name, 2020-10-23) The changes here are purely mechanical replacing "master" with "main" Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

log: add --clear-decorations option

2022-08-05T21:13:12Z

The previous changes introduced a new default ref filter for decorations in the 'git log' command. This can be overridden using --decorate-refs=HEAD and --decorate-refs=refs/, but that is cumbersome for users. Instead, add a --clear-decorations option that resets all previous filters to a blank filter that accepts all refs. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

log: add default decoration filter

2022-08-05T21:13:12Z

When a user runs 'git log', they expect a certain set of helpful decorations. This includes: * The HEAD ref * Branches (refs/heads/) * Stashes (refs/stash) * Tags (refs/tags/) * Remote branches (refs/remotes/) * Replace refs (refs/replace/ or $GIT_REPLACE_REF_BASE) Each of these namespaces was selected due to existing test cases that verify these namespaces appear in the decorations. In particular, stashes and replace refs can have custom colors from the color.decorate. config option. While one test checks for a decoration from notes, it only applies to the tip of refs/notes/commit (or its configured ref name). Notes form their own kind of decoration instead. Modify the expected output for the tests in t4013 that expect this note decoration. There are several tests throughout the codebase that verify that --decorate-refs, --decorate-refs-exclude, and log.excludeDecoration work as designed and the tests continue to pass without intervention. However, there are other refs that are less helpful to show as decoration: * Prefetch refs (refs/prefetch/) * Rebase refs (refs/rebase-merge/ and refs/rebase-apply/) * Bundle refs (refs/bundle/) [!] [!] The bundle refs are part of a parallel series that bootstraps a repo from a bundle file, storing the bundle's refs into the repo's refs/bundle/ namespace. In the case of prefetch refs, 96eaffebbf3d0 (maintenance: set log.excludeDecoration durin prefetch, 2021-01-19) added logic to add refs/prefetch/ to the log.excludeDecoration config option. Additional feedback pointed out that having such a side-effect can be confusing and perhaps not helpful to users. Instead, we should hide these ref namespaces that are being used by Git for internal reasons but are not helpful for the users to see. The way to provide a seamless user experience without setting the config is to modify the default decoration filters to match our expectation of what refs the user actually wants to see. In builtin/log.c, after parsing the --decorate-refs and --decorate-refs-exclude options from the command-line, call set_default_decoration_filter(). This method populates the exclusions from log.excludeDecoration, then checks if the list of pattern modifications are empty. If none are specified, then the default set is restricted to the set of inclusions mentioned earlier (HEAD, branches, etc.). A previous change introduced the ref_namespaces array, which includes all of these currently-used namespaces. The 'decoration' value is non-zero when that namespace is associated with a special coloring and fits into the list of "expected" decorations as described above, which makes the implementation of this filter very simple. Note that the logic in ref_filter_match() in log-tree.c follows this matching pattern: 1. If there are exclusion patterns and the ref matches one, then ignore the decoration. 2. If there are inclusion patterns and the ref matches one, then definitely include the decoration. 3. If there are config-based exclusions from log.excludeDecoration and the ref matches one, then ignore the decoration. With this logic in mind, we need to ensure that we do not populate our new defaults if any of these filters are manually set. Specifically, if a user runs git -c log.excludeDecoration=HEAD log then we expect the HEAD decoration to not appear. If we left the default inclusions in the set, then HEAD would match that inclusion before reaching the config-based exclusions. A potential alternative would be to check the list of default inclusions at the end, after the config-based exclusions. This would still create a behavior change for some uses of --decorate-refs-exclude=, and could be overwritten somewhat with --decorate-refs=refs/ and --decorate-refs=HEAD. However, it no longer becomes possible to include refs outside of the defaults while also excluding some using log.excludeDecoration. Another alternative would be to exclude the known namespaces that are not intended to be shown. This would reduce the visible effect of the change for expert users who use their own custom ref namespaces. The implementation change would be very simple to swap due to our use of ref_namespaces: int i; struct string_list *exclude = decoration_filter->exclude_ref_pattern; /* * No command-line or config options were given, so * populate with sensible defaults. */ for (i = 0; i < NAMESPACE__COUNT; i++) { if (ref_namespaces[i].decoration) continue; string_list_append(exclude, ref_namespaces[i].ref); } The main downside of this approach is that we expect to add new hidden namespaces in the future, and that means that Git versions will be less stable in how they behave as those namespaces are added. It is critical that we provide ways for expert users to disable this behavior change via command-line options and config keys. These changes will be implemented in a future change. Add a test that checks that the defaults are not added when --decorate-refs is specified. We verify this by showing that HEAD is not included as it normally would. Also add a test that shows that the default filter avoids the unwanted decorations from refs/prefetch, refs/rebase-merge, and refs/bundle. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

t4013: test "git diff-tree -m"

2021-05-21T00:24:13Z

We want to ensure we don't affect plumbing commands with our changes of "-m" semantics, so add corresponding test. Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

t4013: test "git log -m --stat"

2021-05-21T00:24:13Z

This is to ensure we won't break different diff formats when we start to imply "-p" by "-m". Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

t4013: test "git log -m --raw"

2021-05-21T00:24:13Z

This is to ensure we won't break different diff formats when we start to imply "-p" by "-m". Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

Merge branch 'so/log-diff-merge'

2021-02-06T00:40:44Z

"git log" learned a new "--diff-merges=" option. * so/log-diff-merge: (32 commits) t4013: add tests for --diff-merges=first-parent doc/git-show: include --diff-merges description doc/rev-list-options: document --first-parent changes merges format doc/diff-generate-patch: mention new --diff-merges option doc/git-log: describe new --diff-merges options diff-merges: add '--diff-merges=1' as synonym for 'first-parent' diff-merges: add old mnemonic counterparts to --diff-merges diff-merges: let new options enable diff without -p diff-merges: do not imply -p for new options diff-merges: implement new values for --diff-merges diff-merges: make -m/-c/--cc explicitly mutually exclusive diff-merges: refactor opt settings into separate functions diff-merges: get rid of now empty diff_merges_init_revs() diff-merges: group diff-merge flags next to each other inside 'rev_info' diff-merges: split 'ignore_merges' field diff-merges: fix -m to properly override -c/--cc t4013: add tests for -m failing to override -c/--cc t4013: support test_expect_failure through ':failure' magic diff-merges: revise revs->diff flag handling diff-merges: handle imply -p on -c/--cc logic for log.c ...

t4013: add tests for --diff-merges=first-parent

2020-12-21T21:47:32Z

This new option provides essential new functionality, changing diff output to first parent only, without changing history traversal mode, so it deserves its own test. As we do it, add additional test that --diff-merges=first-parent by itself doesn't imply -p and only outputs diffs for merge commits. Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

t4013: add tests for -m failing to override -c/--cc

2020-12-21T21:47:31Z

Logically, -m, -c, --cc specify 3 different formats for representing merge commits, yet -m doesn't in fact override -c or --cc, that makes no sense. Add 2 expected to fail tests that demonstrate the problem. Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

Merge branch 'mk/diff-ignore-regex'

2020-11-02T21:17:44Z

"git diff" family of commands learned the "-I" option to ignore hunks whose changed lines all match the given pattern. * mk/diff-ignore-regex: diff: add -I that ignores matching changes merge-base, xdiff: zero out xpparam_t structures