summaryrefslogtreecommitdiff
path: root/t/t6300-for-each-ref.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-12-07t6300: avoid using the default name of the initial branchLibravatar Johannes Schindelin1-88/+90
Our test suite currently only passes when `git init` uses the name `master` for the initial branch. This would stop us from changing the default branch name. Let's adjust t6300 so that it does not rely on any specific default branch name. This trick is done by (force-)renaming the initial branch to the name `main` in the `setup` and the `:remotename and :remoteref` test cases, and then replacing all mentions of `master` and `MASTER` with `main` and `MAIN`, respectively. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09Merge branch 'hv/ref-filter-misc'Libravatar Junio C Hamano1-0/+35
The "--format=" option to the "for-each-ref" command and friends learned a few more tricks, e.g. the ":short" suffix that applies to "objectname" now also can be used for "parent", "tree", etc. * hv/ref-filter-misc: ref-filter: add `sanitize` option for 'subject' atom pretty: refactor `format_sanitized_subject()` ref-filter: add `short` modifier to 'parent' atom ref-filter: add `short` modifier to 'tree' atom ref-filter: rename `objectname` related functions and fields ref-filter: modify error messages in `grab_objectname()` ref-filter: refactor `grab_objectname()` ref-filter: support different email formats
2020-08-31Merge branch 'hv/ref-filter-trailers-atom-parsing-fix'Libravatar Junio C Hamano1-38/+18
The parser for "git for-each-ref --format=..." was too loose when parsing the "%(trailers...)" atom, and forgot that "trailers" and "trailers:<modifiers>" are the only two allowed forms, which has been corrected. * hv/ref-filter-trailers-atom-parsing-fix: ref-filter: 'contents:trailers' show error if `:` is missing t6300: unify %(trailers) and %(contents:trailers) tests
2020-08-28ref-filter: add `sanitize` option for 'subject' atomLibravatar Hariom Verma1-0/+7
Currently, subject does not take any arguments. This commit introduce `sanitize` formatting option to 'subject' atom. `subject:sanitize` - print sanitized subject line, suitable for a filename. e.g. %(subject): "the subject line" %(subject:sanitize): "the-subject-line" Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: add `short` modifier to 'parent' atomLibravatar Hariom Verma1-0/+6
Sometimes while using 'parent' atom, user might want to see abbrev hash instead of full 40 character hash. Just like 'objectname', it might be convenient for users to have the `:short` and `:short=<length>` option for printing 'parent' hash. Let's introduce `short` option to 'parent' atom. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: add `short` modifier to 'tree' atomLibravatar Hariom Verma1-0/+6
Sometimes while using 'tree' atom, user might want to see abbrev hash instead of full 40 character hash. Just like 'objectname', it might be convenient for users to have the `:short` and `:short=<length>` option for printing 'tree' hash. Let's introduce `short` option to 'tree' atom. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28ref-filter: support different email formatsLibravatar Hariom Verma1-0/+16
Currently, ref-filter only supports printing email with angle brackets. Let's add support for two more email options. - trim : for email without angle brackets. - localpart : for the part before the @ sign out of trimmed email Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21ref-filter: 'contents:trailers' show error if `:` is missingLibravatar Hariom Verma1-0/+8
The 'contents' atom does not show any error if used with 'trailers' atom and colon is missing before trailers arguments. e.g %(contents:trailersonly) works, while it shouldn't. It is definitely not an expected behavior. Let's fix this bug. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-21t6300: unify %(trailers) and %(contents:trailers) testsLibravatar Hariom Verma1-42/+14
Currently, there are different tests for testing %(trailers) and %(contents:trailers) causing redundant copy. Its time to get rid of duplicate code. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-31t6300: fix issues related to %(contents:size)Libravatar Alban Gruin1-2/+2
b6839fda68 (ref-filter: add support for %(contents:size), 2020-07-16) added a new format for ref-filter, and added a function to generate tests for this new feature in t6300. Unfortunately, it tries to run `test_expect_sucess' instead of `test_expect_success', and writes $expect to `expected', but tries to read `expect'. Those two issues were probably unnoticed because the script only printed errors, but did not crash. This fixes these issues. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16ref-filter: add support for %(contents:size)Libravatar Christian Couder1-0/+19
It's useful and efficient to be able to get the size of the contents directly without having to pipe through `wc -c`. Also the result of the following: `git for-each-ref --format='%(contents)' refs/heads/my-branch | wc -c` is off by one as `git for-each-ref` appends a newline character after the contents, which can be seen by comparing its output with the output from `git cat-file`. As with %(contents), %(contents:size) is silently ignored, if a ref points to something other than a commit or a tag: ``` $ git update-ref refs/mytrees/first HEAD^{tree} $ git for-each-ref --format='%(contents)' refs/mytrees/first $ git for-each-ref --format='%(contents:size)' refs/mytrees/first ``` Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-10t6300: test refs pointing to tree and blobLibravatar Christian Couder1-0/+19
Adding tests for refs pointing to tree and blob shows that we care about testing both positive ("see, my shiny new toy does work") and negative ("and it won't do nonsensical things when given an input it is not designed to work with") cases. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-08Merge branch 'jk/for-each-ref-multi-key-sort-fix'Libravatar Junio C Hamano1-6/+88
"git branch" and other "for-each-ref" variants accepted multiple --sort=<key> options in the increasing order of precedence, but it had a few breakages around "--ignore-case" handling, and tie-breaking with the refname, which have been fixed. * jk/for-each-ref-multi-key-sort-fix: ref-filter: apply fallback refname sort only after all user sorts ref-filter: apply --ignore-case to all sorting keys
2020-05-04ref-filter: apply fallback refname sort only after all user sortsLibravatar Jeff King1-6/+48
Commit 9e468334b4 (ref-filter: fallback on alphabetical comparison, 2015-10-30) taught ref-filter's sort to fallback to comparing refnames. But it did it at the wrong level, overriding the comparison result for a single "--sort" key from the user, rather than after all sort keys have been exhausted. This worked correctly for a single "--sort" option, but not for multiple ones. We'd break any ties in the first key with the refname and never evaluate the second key at all. To make matters even more interesting, we only applied this fallback sometimes! For a field like "taggeremail" which requires a string comparison, we'd truly return the result of strcmp(), even if it was 0. But for numerical "value" fields like "taggerdate", we did apply the fallback. And that's why our multiple-sort test missed this: it uses taggeremail as the main comparison. So let's start by adding a much more rigorous test. We'll have a set of commits expressing every combination of two tagger emails, dates, and refnames. Then we can confirm that our sort is applied with the correct precedence, and we'll be hitting both the string and value comparators. That does show the bug, and the fix is simple: moving the fallback to the outer compare_refs() function, after all ref_sorting keys have been exhausted. Note that in the outer function we don't have an "ignore_case" flag, as it's part of each individual ref_sorting element. It's debatable what such a fallback should do, since we didn't use the user's keys to match. But until now we have been trying to respect that flag, so the least-invasive thing is to try to continue to do so. Since all callers in the current code either set the flag for all keys or for none, we can just pull the flag from the first key. In a hypothetical world where the user really can flip the case-insensitivity of keys separately, we may want to extend the code to distinguish that case from a blanket "--ignore-case". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04ref-filter: apply --ignore-case to all sorting keysLibravatar Jeff King1-0/+40
All of the ref-filter users (for-each-ref, branch, and tag) take an --ignore-case option which makes filtering and sorting case-insensitive. However, this option was applied only to the first element of the ref_sorting list. So: git for-each-ref --ignore-case --sort=refname would do what you expect, but: git for-each-ref --ignore-case --sort=refname --sort=taggername would sort the primary key (taggername) case-insensitively, but sort the refname case-sensitively. We have two options here: - teach callers to set ignore_case on the whole list - replace the ref_sorting list with a struct that contains both the list of sorting keys, as well as options that apply to _all_ keys I went with the first one here, as it gives more flexibility if we later want to let the users set the flag per-key (presumably through some special syntax when defining the key; for now it's all or nothing through --ignore-case). The new test covers this by sorting on both tagger and subject case-insensitively, which should compare "a" and "A" identically, but still sort them before "b" and "B". We'll break ties by sorting on the refname to give ourselves a stable output (this is actually supposed to be done automatically, but there's another bug which will be fixed in the next commit). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24t6300: make hash algorithm independentLibravatar brian m. carlson1-1/+1
One of the git for-each-ref tests asks to sort by object ID. However, when sorted, the order of the refs differs between SHA-1 and SHA-256. Sort the expected output so that the test passes. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24t6300: abstract away SHA-1-specific constantsLibravatar brian m. carlson1-9/+16
Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-09Merge branch 'mp/for-each-ref-missing-name-or-email'Libravatar Junio C Hamano1-0/+19
"for-each-ref" and friends that shows refs did not protect themselves against ancient tags that did not record tagger names when asked to show "%(taggername)", which have been corrected. * mp/for-each-ref-missing-name-or-email: ref-filter: initialize empty name or email fields
2019-08-22ref-filter: initialize empty name or email fieldsLibravatar Mischa POSLAWSKY1-0/+19
Formatting $(taggername) on headerless tags such as v0.99 in Git causes a SIGABRT with error "munmap_chunk(): invalid pointer", because of an oversight in commit f0062d3b74 (ref-filter: free item->value and item->value->s, 2018-10-19). Signed-off-by: Mischa POSLAWSKY <git@shiar.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27ref-filter.c: find disjoint pattern prefixesLibravatar Taylor Blau1-0/+26
Since cfe004a5a9 (ref-filter: limit traversal to prefix, 2017-05-22), the ref-filter code has sought to limit the traversals to a prefix of the given patterns. That code stopped short of handling more than one pattern, because it means invoking 'for_each_ref_in' multiple times. If we're not careful about which patterns overlap, we will output the same refs multiple times. For instance, consider the set of patterns 'refs/heads/a/*', 'refs/heads/a/b/c', and 'refs/tags/v1.0.0'. If we naïvely ran: for_each_ref_in("refs/heads/a/*", ...); for_each_ref_in("refs/heads/a/b/c", ...); for_each_ref_in("refs/tags/v1.0.0", ...); we would see 'refs/heads/a/b/c' (and everything underneath it) twice. Instead, we want to partition the patterns into disjoint sets, where we know that no ref will be matched by any two patterns in different sets. In the above, these are: - {'refs/heads/a/*', 'refs/heads/a/b/c'}, and - {'refs/tags/v1.0.0'} Given one of these disjoint sets, what is a suitable pattern to pass to 'for_each_ref_in'? One approach is to compute the longest common prefix over all elements in that disjoint set, and let the caller cull out the refs they didn't want. Computing the longest prefix means that in most cases, we won't match too many things the caller would like to ignore. The longest common prefixes of the above are: - {'refs/heads/a/*', 'refs/heads/a/b/c'} -> refs/heads/a/* - {'refs/tags/v1.0.0'} -> refs/tags/v1.0.0 We instead invoke: for_each_ref_in("refs/heads/a/*", ...); for_each_ref_in("refs/tags/v1.0.0", ...); Which provides us with the refs we were looking for with a minimal amount of extra cruft, but never a duplicate of the ref we asked for. Implemented here is an algorithm which accomplishes the above, which works as follows: 1. Lexicographically sort the given list of patterns. 2. Initialize 'prefix' to the empty string, where our goal is to build each element in the above set of longest common prefixes. 3. Consider each pattern in the given set, and emit 'prefix' if it reaches the end of a pattern, or touches a wildcard character. The end of a string is treated as if it precedes a wildcard. (Note that there is some room for future work to detect that, e.g., 'a?b' and 'abc' are disjoint). 4. Otherwise, recurse on step (3) with the slice of the list corresponding to our current prefix (i.e., the subset of patterns that have our prefix as a literal string prefix.) This algorithm is 'O(kn + n log(n))', where 'k' is max(len(pattern)) for each pattern in the list, and 'n' is len(patterns). By discovering this set of interesting patterns, we reduce the runtime of multi-pattern 'git for-each-ref' (and other ref traversals) from O(N) to O(n log(N)), where 'N' is the total number of packed references. Running 'git for-each-ref refs/tags/a refs/tags/b' on a repository with 10,000,000 refs in 'refs/tags/huge-N', my best-of-five times drop from: real 0m5.805s user 0m5.188s sys 0m0.468s to: real 0m0.001s user 0m0.000s sys 0m0.000s On linux.git, the times to dig out two of the latest -rc tags drops from 0.002s to 0.001s, so the change on repositories with fewer tags is much less noticeable. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-18ref-filter: use correct branch for %(push:track)Libravatar Damien Robert1-2/+11
In ref-filter.c, when processing the atom %(push:track), the ahead/behind values are computed using `stat_tracking_info` which refers to the upstream branch. Fix that by introducing a new flag `for_push` in `stat_tracking_info` in remote.c, which does the same thing but for the push branch. Update the few callers of `stat_tracking_info` to handle this flag. This ensure that whenever we use this function in the future, we are careful to specify is this should apply to the upstream or the push branch. This bug was not detected in t/t6300-for-each-ref.sh because in the test for push:track, both the upstream and the push branches were behind by 1 from the local branch. Change the test so that the upstream branch is behind by 1 while the push branch is ahead by 1. This allows us to test that %(push:track) refers to the correct branch. This changes the expected value of some following tests (by introducing new references), so update them too. Signed-off-by: Damien Robert <damien.olivier.robert+git@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28ref-filter: add tests for deltabaseLibravatar Olga Telezhnaya1-0/+3
Test new formatting option deltabase. Signed-off-by: Olga Telezhnaia <olyatelezhnaya@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28ref-filter: add tests for objectsize:diskLibravatar Olga Telezhnaya1-0/+3
Test new formatting atom. Signed-off-by: Olga Telezhnaia <olyatelezhnaya@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-17Merge branch 'jk/trailer-fixes'Libravatar Junio C Hamano1-0/+23
"git interpret-trailers" and its underlying machinery had a buggy code that attempted to ignore patch text after commit log message, which triggered in various codepaths that will always get the log message alone and never get such an input. * jk/trailer-fixes: append_signoff: use size_t for string offsets sequencer: ignore "---" divider when parsing trailers pretty, ref-filter: format %(trailers) with no_divider option interpret-trailers: allow suppressing "---" divider interpret-trailers: tighten check for "---" patch boundary trailer: pass process_trailer_opts to trailer_info_get() trailer: use size_t for iterating trailer list trailer: use size_t for string offsets
2018-08-23pretty, ref-filter: format %(trailers) with no_divider optionLibravatar Jeff King1-0/+23
In both of these cases we know that we are feeding the trailer-parsing code a pure commit message. We should tell it so, which avoids false positives for a commit message that contains a "---" line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-2/+1
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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-24Merge branch 'jk/for-each-ref-icase'Libravatar Junio C Hamano1-0/+11
The "--ignore-case" option of "git for-each-ref" (and its friends) did not work correctly, which has been fixed. * jk/for-each-ref-icase: ref-filter: avoid backend filtering with --ignore-case for-each-ref: consistently pass WM_IGNORECASE flag t6300: add a test for --ignore-case
2018-07-03ref-filter: avoid backend filtering with --ignore-caseLibravatar Jeff King1-1/+1
When for-each-ref is used with --ignore-case, we expect match_name_as_path() to do a case-insensitive match. But there's an extra layer of filtering that happens before we even get there. Since commit cfe004a5a9 (ref-filter: limit traversal to prefix, 2017-05-22), we feed the prefix to the ref backend so that it can optimize the ref iteration. There's no mechanism for us to tell the backend we're matching case-insensitively. Nor is there likely to be one anytime soon, since the packed backend relies on binary-searching the sorted list of refs. Let's just punt on this case. The extra filtering is an optimization that we simply can't do. We'll still give the correct answer via the filtering in match_name_as_path(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6300: add a test for --ignore-caseLibravatar Jeff King1-0/+11
The --ignore-case option was added by 3bb16a8bf2 (tag, branch, for-each-ref: add --ignore-case for sorting and filtering, 2016-12-04), but it was never tested. And indeed, it does not work due to multiple bugs (which will be fixed in subsequent patches). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: switch $_z40 to $ZERO_OIDLibravatar brian m. carlson1-1/+1
Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-13t6300-for-each-ref: fix "more than one quoting style" testsLibravatar SZEDER Gábor1-5/+2
'git for-each-ref' should error out when invoked with more than one quoting style options. The tests checking this have two issues: - They run 'git for-each-ref' upstream of a pipe, hiding its exit code, thus don't actually checking that 'git for-each-ref' exits with error code. - They check the error message in a rather roundabout way. Ensure that 'git for-each-ref' exits with an error code using the 'test_must_fail' helper function, and check its error message by grepping its saved standard error. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15Merge branch 'js/for-each-ref-remote-name-and-ref'Libravatar Junio C Hamano1-0/+32
The "--format=..." option "git for-each-ref" takes learned to show the name of the 'remote' repository and the ref at the remote side that is affected for 'upstream' and 'push' via "%(push:remotename)" and friends. * js/for-each-ref-remote-name-and-ref: for-each-ref: test :remotename and :remoteref for-each-ref: let upstream/push report the remote ref name for-each-ref: let upstream/push optionally report the remote name
2017-11-08for-each-ref: test :remotename and :remoterefLibravatar Johannes Schindelin1-0/+32
This not only prevents regressions, but also serves as documentation what this new feature is expected to do. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-18Merge branch 'jk/ref-filter-colors-fix'Libravatar Junio C Hamano1-0/+5
This is the "theoretically more correct" approach of simply stepping back to the state before plumbing commands started paying attention to "color.ui" configuration variable. Let's run with this one. * jk/ref-filter-colors-fix: tag: respect color.ui config Revert "color: check color.ui in git_default_config()" Revert "t6006: drop "always" color config tests" Revert "color: make "always" the same as "auto" in config"
2017-10-17tag: respect color.ui configLibravatar Jeff King1-0/+5
Since 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), we expect that setting "color.ui" to "always" will enable color tag formats even without a tty. As that commit was built on top of 136c8c8b8f (color: check color.ui in git_default_config(), 2017-07-13) from the same series, we didn't need to touch tag's config parsing at all. However, since we reverted 136c8c8b8f, we now need to explicitly call git_color_default_config() to make this work. Let's do so, and also restore the test dropped in 0c88bf5050 (provide --color option for all ref-filter users, 2017-10-03). That commit swapped out our "color.ui=always" test for "--color" in preparation for "always" going away. But since it is here to stay, we should test both cases. Note that for-each-ref also lost its color.ui support as part of reverting 136c8c8b8f. But as a plumbing command, it should _not_ respect the color.ui config. Since it also gained a --color option in 0c88bf5050, that's the correct way to ask it for color. We'll continue to test that, and confirm that "color.ui" is not respected. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-11Merge branch 'tb/show-trailers-in-ref-filter'Libravatar Junio C Hamano1-2/+88
"git for-each-ref --format=..." learned a new format element, %(trailers), to show only the commit log trailer part of the log message. * tb/show-trailers-in-ref-filter: ref-filter.c: parse trailers arguments with %(contents) atom ref-filter.c: use trailer_opts to format trailers t6300: refactor %(trailers) tests doc: use "`<literal>`"-style quoting for literal strings doc: 'trailers' is the preferred way to format trailers t4205: unfold across multiple lines
2017-10-07Merge branch 'tb/ref-filter-empty-modifier'Libravatar Junio C Hamano1-0/+1
In the "--format=..." option of the "git for-each-ref" command (and its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)" (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat them as if the colon and an empty string that follows it were not there. * tb/ref-filter-empty-modifier: ref-filter.c: pass empty-string as NULL to atom parsers
2017-10-05ref-filter.c: pass empty-string as NULL to atom parsersLibravatar Taylor Blau1-0/+1
Peff points out that different atom parsers handle the empty "sub-argument" list differently. An example of this is the format "%(refname:)". Since callers often use `string_list_split` (which splits the empty string with any delimiter as a 1-ary string_list containing the empty string), this makes handling empty sub-argument strings non-ergonomic. Let's fix this by declaring that atom parser implementations must not care about distinguishing between the empty string "%(refname:)" and no sub-arguments "%(refname)". Current code aborts, either with "unrecognised arg" (e.g. "refname:") or "does not take args" (e.g. "body:") as an error message. Signed-off-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04provide --color option for all ref-filter usersLibravatar Jeff King1-2/+2
When ref-filter learned about want_color() in 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), it became useful to be able to turn colors off and on for specific commands. For git-branch, you can do so with --color/--no-color. But for git-for-each-ref and git-tag, the other users of ref-filter, you have no option except to tweak the "color.ui" config setting. Let's give both of these commands the usual color command-line options. This is a bit more obvious as a method for overriding the config. And it also prepares us for the behavior of "always" changing (so that we are still left with a way of forcing color when our output goes to a non-terminal). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04test-terminal: set TERM=vt100Libravatar Jeff King1-2/+1
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 test-lib.sh 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02ref-filter.c: parse trailers arguments with %(contents) atomLibravatar Taylor Blau1-0/+38
The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no arguments are given (see: `parse_ref_filter_atom`). This is because string_list_split (given a maxsplit of -1) returns a 1-ary string_list* containing the given string if the delimiter could not be found using `strchr`. To simulate this behavior without teaching trailers_atom_parser to accept strings with length zero, conditionally pass NULL to trailers_atom_parser if the arguments portion of the argument to %(contents) is empty. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02ref-filter.c: use trailer_opts to format trailersLibravatar Taylor Blau1-0/+41
Fill trailer_opts with "unfold" and "only" to match the sub-arguments given to the "%(trailers)" atom. Then, let's use the filled trailer_opts instance with 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02t6300: refactor %(trailers) testsLibravatar Taylor Blau1-2/+9
We currently have one test for %(trailers) in `git-for-each-ref(1)`, through "%(contents:trailers)". In preparation for more, let's add a few things: - Move the commit creation step to its own test so that it can be re-used. - Add a non-trailer to the commit's trailers to test that non-trailers aren't shown using "%(trailers:only)". - Add a multi-line trailer to ensure that trailers are unfolded correctly using "%(trailers:unfold)". Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13ref-filter: consult want_color() before emitting colorsLibravatar Jeff King1-11/+26
When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13t: use test_decode_color rather than literal ANSI codesLibravatar Jeff King1-10/+8
When we put literal ANSI terminal codes into our test scripts, it makes diffs on those scripts hard to read (the colors may be indistinguishable from diff coloring, or in the case of a reset, may not be visible at all). Some scripts get around this by including human-readable names and converting to literal codes with a git-config hack. This makes the actual code diffs look OK, but test_cmp output suffers from the same problem. Let's use test_decode_color instead, which turns the codes into obvious text tags. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-10Merge branch 'jk/t6300-cleanup'Libravatar Junio C Hamano1-1/+1
A test that creates a confusing branch whose name is HEAD has been corrected not to do so. * jk/t6300-cleanup: t6300: avoid creating refs/heads/HEAD
2017-02-27t6300: avoid creating refs/heads/HEADLibravatar Jeff King1-1/+1
In one test, we use "git checkout --orphan HEAD" to create an unborn branch. Confusingly, the resulting branch is named "refs/heads/HEAD". The original probably meant something like: git checkout --orphan orphaned-branch HEAD Let's just use "orphaned-branch" here to make this less confusing. Putting HEAD in the second argument is already implied. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-07ref-filter: resurrect "strip" as a synonym to "lstrip"Libravatar Junio C Hamano1-0/+12
We forgot that "strip" was introduced at 0571979bd6 ("tag: do not show ambiguous tag names as "tags/foo"", 2016-01-25) as part of Git 2.8 (and 2.7.1) when we started calling this "lstrip" to make it easier to explain the new "rstrip" operation. We shouldn't have renamed the existing one; "lstrip" should have been a new synonym that means the same thing as "strip". Scripts in the wild are surely using the original form already. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnamesLibravatar Karthik Nayak1-0/+19
Complimenting the existing 'lstrip=<N>' option, add an 'rstrip=<N>' option which strips `<N>` slash-separated path components from the end of the refname (e.g., `%(refname:rstrip=2)` turns `refs/tags/foo` into `refs`). Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'Libravatar Karthik Nayak1-6/+6
Currently the 'lstrip=<N>' option only takes a positive value '<N>' and strips '<N>' slash-separated path components from the left. Modify the 'lstrip' option to also take a negative number '<N>' which would strip from the left as necessary and _leave_ behind only 'N' slash-separated path components from the right-most end. For e.g. %(refname:lstrip=-1) would make 'foo/goo/abc' into 'abc'. Add documentation and tests for the same. Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>