summaryrefslogtreecommitdiff
path: root/t/t6300-for-each-ref.sh
AgeCommit message (Collapse)AuthorFilesLines
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>
2017-01-10ref-filter: Do not abruptly die when using the 'lstrip=<N>' optionLibravatar Karthik Nayak1-4/+0
Currently when we use the 'lstrip=<N>' option, if 'N' is greater than the number of components available in the refname, we abruptly end program execution by calling die(). This behavior is undesired since a single refname with few components could end program execution. To avoid this, return an empty string whenever the value 'N' is greater than the number of components available, instead of calling die(). Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: rename the 'strip' option to 'lstrip'Libravatar Karthik Nayak1-11/+11
In preparation for the upcoming patch, where we introduce the 'rstrip' option. Rename the 'strip' option to 'lstrip' to remove ambiguity. Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()Libravatar Karthik Nayak1-0/+2
Use the recently introduced refname_atom_parser_internal() within remote_ref_atom_parser(), this provides a common base for all the ref printing atoms, allowing %(upstream) and %(push) to also use the ':strip' option. The atoms '%(push)' and '%(upstream)' will retain the ':track' and ':trackshort' atom modifiers to themselves as they have no meaning in context to the '%(refname)' and '%(symref)' atoms. Update the documentation and tests to reflect the same. Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: introduce refname_atom_parser()Libravatar Karthik Nayak1-0/+9
Using refname_atom_parser_internal(), introduce refname_atom_parser() which will parse the %(symref) and %(refname) atoms. Store the parsed information into the 'used_atom' structure based on the modifiers used along with the atoms. Now the '%(symref)' atom supports the ':strip' atom modifier. Update the Documentation and tests to reflect this. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: make "%(symref)" atom work with the ':short' modifierLibravatar Karthik Nayak1-0/+24
The "%(symref)" atom doesn't work when used with the ':short' modifier because we strictly match only 'symref' for setting the 'need_symref' indicator. Fix this by comparing with the valid_atom rather than the used_atom. Add tests for %(symref) and %(symref:short) while we're here. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: add support for %(upstream:track,nobracket)Libravatar Karthik Nayak1-0/+2
Add support for %(upstream:track,nobracket) which will print the tracking information without the brackets (i.e. "ahead N, behind M"). This is needed when we port branch.c to use ref-filter's printing APIs. Add test and documentation for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreamsLibravatar Karthik Nayak1-1/+1
Borrowing from branch.c's implementation print "[gone]" whenever an unknown upstream ref is encountered instead of just ignoring it. This makes sure that when branch.c is ported over to using ref-filter APIs for printing, this feature is not lost. Make changes to t/t6300-for-each-ref.sh and Documentation/git-for-each-ref.txt to reflect this change. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Helped-by : Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10ref-filter: modify "%(objectname:short)" to take lengthLibravatar Karthik Nayak1-0/+10
Add support for %(objectname:short=<length>) which would print the abbreviated unique objectname of given length. When no length is specified, the length is 'DEFAULT_ABBREV'. The minimum length is 'MINIMUM_ABBREV'. The length may be exceeded to ensure that the provided object name is unique. Add tests and documentation for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Helped-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-19Merge branch 'jk/trailers-placeholder-in-pretty'Libravatar Junio C Hamano1-0/+25
In addition to %(subject), %(body), "log --pretty=format:..." learned a new placeholder %(trailers). * jk/trailers-placeholder-in-pretty: ref-filter: add support to display trailers as part of contents pretty: add %(trailers) format for displaying trailers of a commit message
2016-12-11ref-filter: add support to display trailers as part of contentsLibravatar Jacob Keller1-0/+26
Add %(trailers) and %(contents:trailers) to display the trailers as interpreted by trailer_info_get. Update documentation and add a test for the new feature. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-18for-each-ref: do not segv with %(HEAD) on an unborn branchLibravatar Junio C Hamano1-0/+10
The code to flip between "*" and " " prefixes depending on what branch is checked out used in --format='%(HEAD)' did not consider that HEAD may resolve to an unborn branch and dereferenced a NULL. This will become a lot easier to trigger as the codepath will be used to reimplement "git branch [--list]" in the future. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King1-0/+12
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25t6300: use test_atom for some un-modern testsLibravatar Jeff King1-52/+10
Because this script has to test so many formatters, we have the nice "test_atom" helper, but we don't use it consistently. Let's do so. This is shorter, gets rid of some tests that have their "expected" setup outside of a test_expect_success block, and lets us organize the changes better (e.g., putting "refname:short" near "refname"). We also expand the "%(push)" tests a little to match the "%(upstream)" ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05Merge branch 'jk/date-local'Libravatar Junio C Hamano1-67/+95
"git log --date=local" used to only show the normal (default) format in the local timezone. The command learned to take 'local' as an instruction to use the local timezone with other formats, e.g. "git show --date=rfc-local". * jk/date-local: t6300: add tests for "-local" date formats t6300: make UTC and local dates different date: make "local" orthogonal to date format date: check for "local" before anything else t6300: add test for "raw" date format t6300: introduce test_date() helper fast-import: switch crash-report date to iso8601 Documentation/rev-list: don't list date formats Documentation/git-for-each-ref: don't list date formats Documentation/config: don't list date formats Documentation/blame-options: don't list date formats
2015-09-03t6300: add tests for "-local" date formatsLibravatar John Keeping1-0/+36
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03t6300: make UTC and local dates differentLibravatar John Keeping1-35/+35
By setting the UTC time to 23:18:43 the date in +0200 is the following day, 2006-07-04. This will ensure that the test for "short-local" to be added in the following patch tests for different output from the "short" format. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03t6300: add test for "raw" date formatLibravatar John Keeping1-0/+4
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03t6300: introduce test_date() helperLibravatar John Keeping1-52/+40
This moves the setup of the "expected" file inside the test case. The helper function has the advantage that we can use SQ in the file content without needing to escape the quotes. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20strbuf: make strbuf_addftime more robustLibravatar Jeff King1-0/+10
The return value of strftime is poorly designed; when it returns 0, the caller cannot tell if the buffer was not large enough, or if the output was actually 0 bytes. In the original implementation of strbuf_addftime, we simply punted and guessed that our 128-byte hint would be large enough. We can do better, though, if we're willing to treat strftime like less of a black box. We can munge the incoming format to make sure that it never produces 0-length output, and then "fix" the resulting output. That lets us reliably grow the buffer based on strftime's return value. Clever-idea-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>