path: root/t/
AgeCommit message (Collapse)Author
2021-07-28Merge branch 'jk/log-decorate-optim'Junio C Hamano
Optimize "git log" for cases where we wasted cycles to load ref decoration data that may not be needed. * jk/log-decorate-optim: load_ref_decorations(): fix decoration with tags add_ref_decoration(): rename s/type/deco_type/ load_ref_decorations(): avoid parsing non-tag objects object.h: add lookup_object_by_type() function object.h: expand docstring for lookup_unknown_object() log: avoid loading decorations for userformats that don't need it pretty.h: update and expand docstring for userformat_find_requirements()
2021-07-14load_ref_decorations(): fix decoration with tagsJeff King
Commit 88473c8bae ("load_ref_decorations(): avoid parsing non-tag objects", 2021-06-22) introduced a shortcut to `add_ref_decoration()`: Rather than calling `parse_object()`, we go for `oid_object_info()` and then `lookup_object_by_type()` using the type just discovered. As detailed in the commit message, this provides a significant time saving. Unfortunately, it also changes the behavior: We lose all annotated tags from the decoration. The reason this happens is in the loop where we try to peel the tags, we won't necessarily have parsed that first object. If we haven't, its `tagged` field will be NULL, so we won't actually add a decoration for the pointed-to object. Make sure to parse the tag object at the top of the peeling loop. This effectively restores the pre-88473c8bae parsing -- but only of tags, allowing us to keep most of the possible speedup from 88473c8bae. On my big ~220k ref test case (where it's mostly non-tags), the timings [using "git log -1 --decorate"] are: - before either patch: 2.945s - with my broken patch: 0.707s - with [this patch]: 0.788s The simplest way to do this is to just conditionally parse before the loop: if (obj->type == OBJ_TAG) parse_object(&obj->oid); But we can observe that our tag-peeling loop needs to peel already, to examine recursive tags-of-tags. So instead of introducing a new call to parse_object(), we can simply move the parsing higher in the loop: instead of parsing the new object before we loop, parse each tag object before we look at its "tagged" field. This has another beneficial side effect: if a tag points at a commit (or other non-tag type), we do not bother to parse the commit at all now. And we know it is a commit without calling oid_object_info(), because parsing the surrounding tag object will have created the correct in-core object based on the "type" field of the tag. Our test coverage for --decorate was obviously not good, since we missed this quite-basic regression. The new tests covers an annotated tag (showing the fix), but also that we correctly show annotations for lightweight tags and double-annotated tag-of-tags. Reported-by: Martin Ågren <> Helped-by: Martin Ågren <> Signed-off-by: Martin Ågren <> Signed-off-by: Jeff King <> Reviewed-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2021-06-02t4202: mark bogus head hash test with REFFILESHan-Wen Nienhuys
In reftable, hashes are correctly formed by design. Split off test for git-log in empty repo. Signed-off-by: Han-Wen Nienhuys <> Reviewed-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-06-02t4202: split testcase for invalid HEAD symref and HEAD hashHan-Wen Nienhuys
Reftable will prohibit invalid hashes at the storage level, but git-symbolic-ref can still create branches ending in ".lock". Signed-off-by: Han-Wen Nienhuys <> Signed-off-by: Junio C Hamano <>
2020-11-19t4*: adjust the references to the default branch name "main"Johannes Schindelin
Carefully excluding t4013 and t4015, which see independent development elsewhere at the time of writing, we use `main` as the default branch name in t4*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t4*.sh t4211/*.export && git checkout HEAD -- t4013\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Johannes Schindelin
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ \ t/ t/ \ t/ \ t/ t/ \ t/ We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-08-31Merge branch 'jk/rev-input-given-fix'Junio C Hamano
Feeding "$ZERO_OID" to "git log --ignore-missing --stdin", and running "git log --ignore-missing $ZERO_OID" fell back to start digging from HEAD; it has been corrected to become a no-op, like "git log --tags=no-tag-matches-this-pattern" does. * jk/rev-input-given-fix: revision: set rev_input_given in handle_revision_arg()
2020-08-26revision: set rev_input_given in handle_revision_arg()Jeff King
Commit 7ba826290a (revision: add rev_input_given flag, 2017-08-02) added a flag to rev_info to tell whether we got any revision arguments. As explained there, this is necessary because some revision arguments may not produce any pending traversal objects, but should still inhibit default behaviors (e.g., a glob that matches nothing). However, it only set the flag in the globbing code, but not for revisions we get on the command-line or via stdin. This leads to two problems: - the command-line code keeps its own separate got_rev_arg flag; this isn't wrong, but it's confusing and an extra maintenance burden - even specifically-named rev arguments might end up not adding any pending objects: if --ignore-missing is set, then specifying a missing object is a noop rather than an error. And that leads to some user-visible bugs: - when deciding whether a default rev like "HEAD" should kick in, we check both got_rev_arg and rev_input_given. That means that "--ignore-missing $ZERO_OID" works on the command-line (where we set got_rev_arg) but not on --stdin (where we don't) - when rev-list decides whether it should complain that it wasn't given a starting point, it relies on rev_input_given. So it can't even get the command-line "--ignore-missing $ZERO_OID" right Let's consistently set the flag if we got any revision argument. That lets us clean up the redundant got_rev_arg, and fixes both of those bugs (but note there are three new tests: we'll confirm the already working git-log command-line case). A few implementation notes: - conceptually we want to set the flag whenever handle_revision_arg() finds an actual revision arg ("handles" it, you might say). But it covers a ton of cases with early returns. Rather than annotating each one, we just wrap it and use its success exit-code to set the flag in one spot. - the new rev-list test is in t6018, which is titled to cover globs. This isn't exactly a glob, but it made sense to stick it with the other tests that handle the "even though we got a rev, we have no pending objects" case, which are globs. - the tests check for the oid of a missing object, which it's pretty clear --ignore-missing should ignore. You can see the same behavior with "--ignore-missing a-ref-that-does-not-exist", because --ignore-missing treats them both the same. That's perhaps less clearly correct, and we may want to change that in the future. But the way the code and tests here are written, we'd continue to do the right thing even if it does. Reported-by: Bryan Turner <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2020-07-30Revert "fmt-merge-msg: stop treating `master` specially"Junio C Hamano
This reverts commit 489947cee5095b168cbac111ff7bd1eadbbd90dd, which stopped treating merges into the 'master' branch as special when preparing the default merge message. As the goal was not to have any single branch designated as special, it solved it by leaving the "into <branchname>" at the end of the title of the default merge message for any and all branches. An obvious and easy alternative to treat everybody equally could have been to remove it for every branch, but that involves loss of information. We'll introduce a new mechanism to let end-users specify merges into which branches would omit the "into <branchname>" from the title of the default merge message, and make the mechanism, when unconfigured, treat the traditional 'master' special again, so all the changes to the tests we made earlier will become unnecessary, as these tests will be run without configuring the said new mechanism. Signed-off-by: Junio C Hamano <>
2020-06-24fmt-merge-msg: stop treating `master` speciallyJohannes Schindelin
In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-05-31Merge branch 'cb/test-use-ere-for-alternation'Junio C Hamano
Portability fix for tests added recently. * cb/test-use-ere-for-alternation: t: avoid alternation (not POSIX) in grep's BRE
2020-05-29t: avoid alternation (not POSIX) in grep's BRECarlo Marcelo Arenas Belón
f1e3df3169 (t: increase test coverage of signature verification output, 2020-03-04) adds GPG dependent tests to t4202 and t6200 that were found problematic with at least OpenBSD 6.7. Using an escaped '|' for alternations works only in some implementations of grep (e.g. GNU and busybox). It is not part of POSIX[1] and not supported by some BSD, macOS, and possibly other POSIX compatible implementations. Use `grep -E`, and write it using extended regular expression. [1] Helped-by: Torsten Bögershausen <> Signed-off-by: Carlo Marcelo Arenas Belón <> Signed-off-by: Junio C Hamano <>
2020-04-16log: add log.excludeDecoration config optionDerrick Stolee
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. The documentation is careful to point out that the config value can be overridden by the --decorate-refs option, even though --decorate-refs-exclude would always "win" over --decorate-refs. Since the 'log.excludeDecoration' takes lower precedence to --decorate-refs, and --decorate-refs-exclude takes higher precedence, the struct decoration_filter needed another field. This led also to new logic in load_ref_decorations() and ref_filter_match(). There are several tests in that test the --decorate-refs-(include|exclude) options, so these are extended. Since the expected output is already stored as a file, most tests could simply replace a "--decorate-refs-exclude" option with an in-line config setting. Other tests involve the precedence of the config option compared to command-line options and needed more modification. [1] [2] Helped-by: Junio C Hamano <> Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2020-03-27Merge branch 'hi/gpg-prefer-check-signature'Junio C Hamano
The code to interface with GnuPG has been refactored. * hi/gpg-prefer-check-signature: gpg-interface: prefer check_signature() for GPG verification t: increase test coverage of signature verification output
2020-03-15t: increase test coverage of signature verification outputHans Jerry Illikainen
There weren't any tests for unsuccessful signature verification of signed merge tags shown in 'git log'. There also weren't any tests for the GPG output from 'git fmt-merge-msg'. This was noticed while investigating a buggy refactor that slipped through the test suite; see commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c. This commit adds signature verification tests to the 'log' and 'fmt-merge-msg' builtins. Thanks to Linus Torvalds for reporting and finding the (now reverted) commit that introduced the regression. Note that the "log --show-signature for merged tag with GPG failure" test case is really hacky. It relies on an implementation detail of verify_signed_buffer() -- namely, it assumes that the signature is written to a temporary file whose path is under TMPDIR. The rationale for that test case is to check whether the code path that yields the "No signature" message is reachable on failure. The functionality in log-tree.c that may show this message does some pre-parsing of a possible signature that prevents the GPG interface from being invoked if a signature is actually missing. And I haven't been able to construct a signature that both 1. satisfies that pre-processing, and 2. causes GPG to fail without any sort of output on stderr along the lines of "this is a bogus/corrupt/... signature" (the "No signature" message should only be shown if GPG produce no output). Signed-off-by: Hans Jerry Illikainen <> [jc: fixed missing test title noticed by Dscho] Signed-off-by: Junio C Hamano <>
2020-03-09Merge branch 'hd/show-one-mergetag-fix'Junio C Hamano
"git show" and others gave an object name in raw format in its error output, which has been corrected to give it in hex. * hd/show-one-mergetag-fix: show_one_mergetag: print non-parent in hex form.
2020-03-02show_one_mergetag: print non-parent in hex form.Harald van Dijk
When a mergetag names a non-parent, which can occur after a shallow clone, its hash was previously printed as raw data. Print it in hex form instead. Signed-off-by: Harald van Dijk <> Signed-off-by: Junio C Hamano <>
2020-02-24lib-log-graph: consolidate colored graph cmp logicAbhishek Kumar
Signed-off-by: Abhishek Kumar <> Signed-off-by: Junio C Hamano <>
2020-02-24lib-log-graph: consolidate test_cmp_graph logicAbhishek Kumar
Log graph comparision logic is duplicated many times in: - - - - Consolidate the core of the comparision and sanitization logic in lib-log-graph, and use it to replace the existing tests. While at it, lose the singular/plural transition magic from the sanitize_output helper, which was necessary around 7f814632 ("Use correct grammar in diffstat summary line", 2012-02-01), that has long outlived its usefulness. Signed-off-by: Abhishek Kumar <> Signed-off-by: Junio C Hamano <>
2020-01-15t4202: abstract away SHA-1-specific constantsbrian m. carlson
Adjust the test so that it computes values for object IDs instead of using hard-coded hashes. Additionally, update the sanitize_output function to sanitize the index lines in diff output, since it's clear from the assertions in question that we are not interested in the specific object IDs. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2019-12-05Merge branch 'hi/gpg-optional-pkfp-fix'Junio C Hamano
The code to parse GPG output used to assume incorrectly that the finterprint for the primary key would always be present for a valid signature, which has been corrected. * hi/gpg-optional-pkfp-fix: gpg-interface: limit search for primary key fingerprint gpg-interface: refactor the free-and-xmemdupz pattern
2019-11-23gpg-interface: limit search for primary key fingerprintHans Jerry Illikainen
The VALIDSIG status line from GnuPG with --status-fd is documented to have 9 required and 1 optional fields [1]. The final, and optional, field is used to specify the fingerprint of the primary key that made the signature in case it was made by a subkey. However, this field is only available for OpenPGP signatures; not for CMS/X.509. If the VALIDSIG status line does not have the optional 10th field, the current code will continue reading onto the next status line. And this is the case for non-OpenPGP signatures [1]. The consequence is that a subsequent status line may be considered as the "primary key" for signatures that does not have an actual primary key. Limit the search of these 9 or 10 fields to the single line to avoid this problem. If the 10th field is missing, report that there is no primary key fingerprint. [Reference] [1] GnuPG Details, General status codes;a=blob;f=doc/DETAILS;h=6ce340e8c04794add995e84308bb3091450bd28f;hb=HEAD#l483 The documentation says: VALIDSIG <args> The args are: - <fingerprint_in_hex> - <sig_creation_date> - <sig-timestamp> - <expire-timestamp> - <sig-version> - <reserved> - <pubkey-algo> - <hash-algo> - <sig-class> - [ <primary-key-fpr> ] This status indicates that the signature is cryptographically valid. [...] PRIMARY-KEY-FPR is the fingerprint of the primary key or identical to the first argument. The primary-key-fpr parameter is used for OpenPGP and not available for CMS signatures. [...] Signed-off-by: Hans Jerry Illikainen <> Signed-off-by: Junio C Hamano <>
2019-10-16graph: smooth appearance of collapsing edges on commit linesJames Coglan
When a graph contains edges that are in the process of collapsing to the left, but those edges cross a commit line, the effect is that the edges have a jagged appearance: * |\ | * | \ *-. \ |\ \ \ | | * | | * | | | |/ / * | | |/ / * | |/ * We already takes steps to smooth edges like this when they're expanding; when an edge appears to the right of a merge commit marker on a GRAPH_COMMIT line immediately following a GRAPH_POST_MERGE line, we render it as a `\`: * \ |\ \ | * \ | |\ \ We can make a similar improvement to collapsing edges, making them easier to follow and giving the overall graph a feeling of increased symmetry: * |\ | * | \ *-. \ |\ \ \ | | * | | * | | | |/ / * / / |/ / * / |/ * To do this, we introduce a new special case for edges on GRAPH_COMMIT lines that immediately follow a GRAPH_COLLAPSING line. By retaining a copy of the `mapping` array used to render the GRAPH_COLLAPSING line in the `old_mapping` array, we can determine that an edge is collapsing through the GRAPH_COMMIT line and should be smoothed. Signed-off-by: James Coglan <> Signed-off-by: Junio C Hamano <>
2019-10-07Merge branch 'rs/simplify-by-deco-with-deco-refs-exclude'Junio C Hamano
"git log --decorate-refs-exclude=<pattern>" was incorrectly overruled when the "--simplify-by-decoration" option is used, which has been corrected. * rs/simplify-by-deco-with-deco-refs-exclude: log-tree: call load_ref_decorations() in get_name_decoration() log: test --decorate-refs-exclude with --simplify-by-decoration
2019-09-09log-tree: call load_ref_decorations() in get_name_decoration()René Scharfe
Load a default set of ref name decorations at the first lookup. This frees direct and indirect callers from doing so. They can still do it if they want to use a filter or are interested in full decorations instead of the default short ones -- the first load_ref_decorations() call wins. This means that the load in builtin/log.c::cmd_log_init_finish() is respected even if --simplify-by-decoration is given, as the previously dominating earlier load in handle_revision_opt() is gone. So a filter given with --decorate-refs-exclude is used for simplification in that case, as expected. Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2019-09-09log: test --decorate-refs-exclude with --simplify-by-decorationRené Scharfe
Demonstrate that a decoration filter given with --decorate-refs-exclude is inadvertently overruled by --simplify-by-decoration. Reported-by: Étienne SERVAIS <> Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2019-08-06parse-options: allow --end-of-options as a synonym for "--"Jeff King
The revision option parser recently learned about --end-of-options, but that's not quite enough for all callers. Some of them, like git-log, pick out some options using parse_options(), and then feed the remainder to setup_revisions(). For those cases we need to stop parse_options() from finding more options when it sees --end-of-options, and to retain that option in argv so that setup_revisions() can see it as well. Let's handle this the same as we do "--". We can even piggy-back on the handling of PARSE_OPT_KEEP_DASHDASH, because any caller that wants to retain one will want to retain the other. I've included two tests here. The "log" test covers "--source", which is one of the options it handles with parse_options(), and would fail before this patch. There's also a test that uses the parse-options helper directly. That confirms that the option is handled correctly even in cases without KEEP_DASHDASH or setup_revisions(). I.e., it is safe to use --end-of-options in place of "--" in other programs. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2019-05-14tests: add a special setup where prerequisites failÆvar Arnfjörð Bjarmason
As discussed in [1] there's a regression in the "pu" branch now because a new test implicitly assumed that a previous test guarded by a prerequisite had been run. Add a "GIT_TEST_FAIL_PREREQS" special test setup where we'll skip (nearly) all tests guarded by prerequisites, allowing us to easily emulate those platform where we don't run these tests. As noted in the documentation I'm adding I'm whitelisting the SYMLINKS prerequisite for now. A lot of tests started failing if we lied about not supporting symlinks. It's also unlikely that we'll have a failing test due to a hard dependency on symlinks without that being the obvious cause, so for now it's not worth the effort to make it work. 1. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-11-06Merge branch 'md/exclude-promisor-objects-fix'Junio C Hamano
Operations on promisor objects make sense in the context of only a small subset of the commands that internally use the revisions machinery, but the "--exclude-promisor-objects" option were taken and led to nonsense results by commands like "log", to which it didn't make much sense. This has been corrected. * md/exclude-promisor-objects-fix: exclude-promisor-objects: declare when option is allowed Documentation/git-log.txt: do not show --exclude-promisor-objects
2018-10-23exclude-promisor-objects: declare when option is allowedMatthew DeVore
The --exclude-promisor-objects option causes some funny behavior in at least two commands: log and blame. It causes a BUG crash: $ git log --exclude-promisor-objects BUG: revision.c:2143: exclude_promisor_objects can only be used when fetch_if_missing is 0 Aborted [134] Fix this such that the option is treated like any other unknown option. The commands that must support it are limited, so declare in those commands that the flag is supported. In particular: pack-objects prune rev-list The commands were found by searching for logic which parses --exclude-promisor-objects outside of revision.c. Extra logic outside of revision.c is needed because fetch_if_missing must be turned on before revision.c sees the option or it will BUG-crash. The above list is supported by the fact that no other command is introspectively invoked by another command passing --exclude-promisor-object. Signed-off-by: Matthew DeVore <> Signed-off-by: Junio C Hamano <>
2018-08-20Merge branch 'ab/test-must-be-empty-for-master'Junio C Hamano
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-07-30tests: make use of the test_must_be_empty functionÆvar Arnfjörð Bjarmason
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-07-20gpg-interface t: extend the existing GPG tests with GPGSMHenning Schild
Add test cases to cover the new X509/gpgsm support. Most of them resemble existing ones. They just switch the format to x509 and set the signingkey when creating signatures. Validation of signatures does not need any configuration of git, it does need gpgsm to be configured to trust the key(-chain). Several of the testcases build on top of existing gpg testcases. The commit ships a self-signed key for and configures gpgsm to trust it. Signed-off-by: Henning Schild <> Signed-off-by: Junio C Hamano <>
2017-11-22log: add option to choose which refs to decorateRafael Ascensão
When `log --decorate` is used, git will decorate commits with all available refs. While in most cases this may give the desired effect, under some conditions it can lead to excessively verbose output. Introduce two command line options, `--decorate-refs=<pattern>` and `--decorate-refs-exclude=<pattern>` to allow the user to select which refs are used in decoration. When "--decorate-refs=<pattern>" is given, only the refs that match the pattern are used in decoration. The refs that match the pattern when "--decorate-refs-exclude=<pattern>" is given, are never used in decoration. These options follow the same convention for mixing negative and positive patterns across the system, assuming that the inclusive default is to match all refs available. (1) if there is no positive pattern given, pretend as if an inclusive default positive pattern was given; (2) for each candidate, reject it if it matches no positive pattern, or if it matches any one of the negative patterns. The rules for what is considered a match are slightly different from the rules used elsewhere. Commands like `log --glob` assume a trailing '/*' when glob chars are not present in the pattern. This makes it difficult to specify a single ref. On the other hand, commands like `describe --match --all` allow specifying exact refs, but do not have the convenience of allowing "shorthand refs" like 'refs/heads' or 'heads' to refer to 'refs/heads/*'. The commands introduced in this patch consider a match if: (a) the pattern contains globs chars, and regular pattern matching returns a match. (b) the pattern does not contain glob chars, and ref '<pattern>' exists, or if ref exists under '<pattern>/' This allows both behaviours (allowing single refs and shorthand refs) yet remaining compatible with existent commands. Helped-by: Kevin Daudt <> Helped-by: Junio C Hamano <> Signed-off-by: Rafael Ascensão <> Signed-off-by: Junio C Hamano <>
2017-10-04Merge branch 'jk/ui-color-always-to-auto-maint' into jk/ui-color-always-to-autoJunio C Hamano
* jk/ui-color-always-to-auto-maint: color: make "always" the same as "auto" in config provide --color option for all ref-filter users t3205: use --color instead of color.branch=always t3203: drop "always" color test t6006: drop "always" color config tests t7502: use diff.noprefix for --verbose test t7508: use test_terminal for color output t3701: use test-terminal to collect color output t4015: prefer --color to -c color.diff=always test-terminal: set TERM=vt100
2017-10-04test-terminal: set TERM=vt100Jeff King
The point of the test-terminal script is to simulate in the test scripts an environment where output is going to a real terminal. But since also sets TERM=dumb, the simulation isn't very realistic. The color code will skip auto-coloring for TERM=dumb, leading to us liberally sprinkling test_terminal env TERM=vt100 git ... through the test suite to convince the tests to actually generate colors. Let's set TERM for programs run under test_terminal, which is one less thing for test-writers to remember. In most cases the callers can be simplified, but note there is one interesting case in t4202. It uses test_terminal to check the auto-enabling of --decorate, but the expected output _doesn't_ contain colors (because TERM=dumb suppresses them). Using TERM=vt100 is closer to what the real world looks like; adjust the expected output to match. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-08-02revision: do not fallback to default when rev_input_given is setJeff King
If revs->def is set (as it is in "git log") and there are no pending objects after parsing the user's input, then we show whatever is in "def". But if the user _did_ ask for some input that just happened to be empty (e.g., "--glob" that does not match anything), showing the default revision is confusing. We should just show nothing, as that is what the user's request yielded. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-06-19Merge branch 'ab/pcre-v2'Junio C Hamano
Update "perl-compatible regular expression" support to enable JIT and also allow linking with the newer PCRE v2 library. * ab/pcre-v2: grep: add support for PCRE v2 grep: un-break building with PCRE >= 8.32 without --enable-jit grep: un-break building with PCRE < 8.20 grep: un-break building with PCRE < 8.32 grep: add support for the PCRE v1 JIT API log: add -P as a synonym for --perl-regexp grep: skip pthreads overhead when using one thread grep: don't redundantly compile throwaway patterns under threading
2017-06-02Merge branch 'ab/grep-preparatory-cleanup'Junio C Hamano
The internal implementation of "git grep" has seen some clean-up. * ab/grep-preparatory-cleanup: (31 commits) grep: assert that threading is enabled when calling grep_{lock,unlock} grep: given --threads with NO_PTHREADS=YesPlease, warn pack-objects: fix buggy warning about threads pack-objects & index-pack: add test for --threads warning test-lib: add a PTHREADS prerequisite grep: move is_fixed() earlier to avoid forward declaration grep: change internal *pcre* variable & function names to be *pcre1* grep: change the internal PCRE macro names to be PCRE1 grep: factor test for \0 in grep patterns into a function grep: remove redundant regflags assignments grep: catch a missing enum in switch statement perf: add a comparison test of log --grep regex engines with -F perf: add a comparison test of log --grep regex engines perf: add a comparison test of grep regex engines with -F perf: add a comparison test of grep regex engines perf: emit progress output when unpacking & building perf: add a GIT_PERF_MAKE_COMMAND for when *_MAKE_OPTS won't do grep: add tests to fix blind spots with \0 patterns grep: prepare for testing binary regexes containing rx metacharacters grep: add a test helper function for less verbose -f \0 tests ...
2017-06-02Merge branch 'jk/diff-blob'Junio C Hamano
The result from "git diff" that compares two blobs, e.g. "git diff $commit1:$path $commit2:$path", used to be shown with the full object name as given on the command line, but it is more natural to use the $path in the output and use it to look up .gitattributes. * jk/diff-blob: diff: use blob path for blob/file diffs diff: use pending "path" if it is available diff: use the word "path" instead of "name" for blobs diff: pass whole pending entry in blobinfo handle_revision_arg: record paths for pending objects handle_revision_arg: record modes for "a..b" endpoints t4063: add tests of direct blob diffs get_sha1_with_context: dynamically allocate oc->path get_sha1_with_context: always initialize oc->symlink_path sha1_name: consistently refer to object_context as "oc" handle_revision_arg: add handle_dotdot() helper handle_revision_arg: hoist ".." check out of range parsing handle_revision_arg: stop using "dotdot" as a generic pointer handle_revision_arg: simplify commit reference lookups handle_revision_arg: reset "dotdot" consistently
2017-05-30Merge branch 'jc/name-rev-lw-tag'Junio C Hamano
"git describe --contains" penalized light-weight tags so much that they were almost never considered. Instead, give them about the same chance to be considered as an annotated tag that is the same age as the underlying commit would. * jc/name-rev-lw-tag: name-rev: favor describing with tags and use committer date to tiebreak name-rev: refactor logic to see if a new candidate is a better name
2017-05-26log: add -P as a synonym for --perl-regexpÆvar Arnfjörð Bjarmason
Add a short -P option as a synonym for the longer --perl-regexp, for consistency with the options the corresponding grep invocations accept. This was intentionally omitted in commit 727b6fc3ed ("log --grep: accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified future use. Make it consistent with "grep" rather than to keep it open for future use, and to avoid the confusion of -P meaning different things for grep & log, as is the case with the -G option. As noted in the aforementioned commit the --basic-regexp option can't have a corresponding -G argument, as the log command already uses that for -G<regex>. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-05-24handle_revision_arg: reset "dotdot" consistentlyJeff King
When we are parsing a range like "a..b", we write a temporary NUL over the first ".", so that we can access the names "a" and "b" as C strings. But our restoration of the original "." is done at inconsistent times, which can lead to confusing results. For most calls, we restore the "." after we resolve the names, but before we call verify_non_filename(). This means that when we later call add_pending_object(), the name for the left-hand "a" has been re-expanded to "a..b". You can see this with: git log --source a...b where "b" will be correctly marked with "b", but "a" will be marked with "a...b". Likewise with "a..b" (though you need to use --boundary to even see "a" at all in that case). To top off the confusion, when the REVARG_CANNOT_BE_FILENAME flag is set, we skip the non-filename check, and leave the NUL in place. That means we do report the correct name for "a" in the pending array. But some code paths try to show the whole "a...b" name in error messages, and these erroneously show only "a" instead of "a...b". E.g.: $ git cherry-pick HEAD:foo...HEAD:foo error: object d95f3ad14dee633a758d2e331151e950dd13e4ed is a blob, not a commit error: object d95f3ad14dee633a758d2e331151e950dd13e4ed is a blob, not a commit fatal: Invalid symmetric difference expression HEAD:foo (That last message should be "HEAD:foo...HEAD:foo"; I used cherry-pick because it passes the CANNOT_BE_FILENAME flag). As an interesting side note, cherry-pick actually looks at and re-resolves the arguments from the pending->name fields. So it would have been visibly broken by the first bug, but the effect was canceled out by the second one. This patch makes the whole function consistent by re-writing the NUL immediately after calling verify_non_filename(), and then restoring the "." as appropriate in some error-printing and early-return code paths. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-05-20grep: add a test asserting that --perl-regexp dies when !PCREÆvar Arnfjörð Bjarmason
Add a test asserting that when --perl-regexp (and -P for grep) is given to git-grep & git-log that we die with an error. In developing the PCRE v2 series I introduced a regression where -P would (through control-flow fall-through) become synonymous with basic POSIX matching. I.e. 'git grep -P '[\d]' would match "d" instead of digits. The entire test suite would still pass with this serious regression, since everything that tested for --perl-regexp would be guarded by the PCRE prerequisite, fix that blind-spot by adding tests under !PCRE asserting that git must die when given --perl-regexp or -P. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-05-20log: make --regexp-ignore-case work with --perl-regexpÆvar Arnfjörð Bjarmason
Make the --regexp-ignore-case option work with --perl-regexp. This never worked, and there was no test for this. Fix the bug and add a test. When PCRE support was added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) compile_pcre_regexp() would only check opt->ignore_case, but when the --perl-regexp option was added in commit 727b6fc3ed ("log --grep: accept --basic-regexp and --perl-regexp", 2012-10-03) the code didn't set the opt->ignore_case. Change the test suite to test for -i and --invert-regexp with basic/extended/perl patterns in addition to fixed, which was the only patternType that was tested for before in combination with those options. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-05-20log: add exhaustive tests for pattern style options & configÆvar Arnfjörð Bjarmason
Add exhaustive tests for how the different grep.patternType options & the corresponding command-line options affect git-log. Before this change it was possible to patch revision.c so that the --basic-regexp option was synonymous with --extended-regexp, and --perl-regexp wasn't recognized at all, and still have 100% of the test suite pass. This was because the first test being modified here, added in commit 34a4ae55b2 ("log --grep: use the same helper to set -E/-F options as "git grep"", 2012-10-03), didn't actually check whether we'd enabled extended regular expressions as distinct from re-toggling non-fixed string support. Fix that by changing the pattern to a pattern that'll only match if --extended-regexp option is provided, but won't match under the default --basic-regexp option. Other potential regressions were possible since there were no tests for the rest of the combinations of grep.patternType configuration toggles & corresponding git-log command-line options. Add exhaustive tests for those. The patterns being passed to fixed/basic/extended/PCRE are carefully crafted to return the wrong thing if the grep engine were to pick any other matching method than the one it's told to use. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-05-15builtin/log: honor log.decoratebrian m. carlson
The recent change that introduced autodecorating of refs accidentally broke the ability of users to set log.decorate = false to override it. When the git_log_config was traversed a second time with an option other than log.decorate, the decoration style would be set to the automatic style, even if the user had already overridden it. Instead of setting the option in config parsing, set it in init_log_defaults instead. Add a test for this case. The actual additional config option doesn't matter, but it needs to be something not already set in the configuration file. Signed-off-by: brian m. carlson <> Acked-by: Alex Henrie <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-03-29name-rev: favor describing with tags and use committer date to tiebreakJunio C Hamano
"git name-rev" assigned a phony "far in the future" date to tips of refs that are not pointing at tag objects, and favored names based on a ref with the oldest date. This made it almost impossible for an unannotated tags and branches to be counted as a viable base, which was especially problematic when the command is run with the "--tags" option. If an unannotated tag that points at an ancient commit and an annotated tag that points at a much newer commit reaches the commit that is being named, the old unannotated tag was ignored. Update the "taggerdate" field of the rev-name structure, which is initialized from the tip of ref, to have the committer date if the object at the tip of ref is a commit, not a tag, so that we can optionally take it into account when doing "is this name better?" comparison logic. When "name-rev" is run without the "--tags" option, the general expectation is still to name the commit based on a tag if possible, but use non-tag refs as fallback, and tiebreak among these non-tag refs by favoring names with shorter hops from the tip. The use of a phony "far in the future" date in the original code was an effective way to ensure this expectation is held: a non-tag tip gets the same "far in the future" timestamp, giving precedence to tags, and among non-tag tips, names with shorter hops are preferred over longer hops, without taking the "taggerdate" into account. As we are taking over the "taggerdate" field to store the committer date for tips with commits: (1) keep the original logic when comparing names based on two refs both of which are from refs/tags/; (2) favoring a name based on a ref in refs/tags/ hierarchy over a ref outside the hierarchy; (3) between two names based on a ref both outside refs/tags/, give precedence to a name with shorter hops and use "taggerdate" only to tie-break. A change to t4202 is a natural consequence. The test creates a commit on a branch "side" and points at it with an unannotated tag "refs/tags/side-2". The original code couldn't decide which one to favor at all, and gave a name based on a branch (simply because refs/heads/side sorts earlier than refs/tags/side-2). Because the updated logic is taught to favor refs in refs/tags/ hierarchy, the the test is updated to expect to see tags/side-2 instead. [mjg: open-coded the comparisons in is_better_name(), dropping a helper macro used in the original] Signed-off-by: Junio C Hamano <> Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2017-03-24log: if --decorate is not given, default to --decorate=autoAlex Henrie
Signed-off-by: Alex Henrie <> Signed-off-by: Junio C Hamano <>
2017-02-10Merge branch 'jk/log-graph-name-only'Junio C Hamano
"git log --graph" did not work well with "--name-only", even though other forms of "diff" output were handled correctly. * jk/log-graph-name-only: diff: print line prefix for --name-only output