development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-09-12 21:04:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
git/t/t6300-for-each-ref.sh

1041 lines
32 KiB
Bash
Raw Normal View History

Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
#!/bin/sh
#
# Copyright (c) 2007 Andy Parkins
#
test_description='for-each-ref test'
. ./test-lib.sh
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
. "$TEST_DIRECTORY"/lib-gpg.sh
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
. "$TEST_DIRECTORY"/lib-terminal.sh
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
# Mon Jul 3 23:18:43 2006 +0000
datestamp=1151968723
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
setdate_and_increment () {
GIT_COMMITTER_DATE="$datestamp +0200"
datestamp=$(expr "$datestamp" + 1)
GIT_AUTHOR_DATE="$datestamp +0200"
datestamp=$(expr "$datestamp" + 1)
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
}
t6300 (for-each-ref): clearly demarcate setup Condense the two-step setup into one step, and give it an appropriate name. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:08 +00:00
test_expect_success setup '
t6300: abstract away SHA-1-specific constants 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>
2020-02-22 20:17:32 +00:00
test_oid_cache <<-EOF &&
disklen sha1:138
disklen sha256:154
EOF
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
setdate_and_increment &&
echo "Using $datestamp" > one &&
git add one &&
git commit -m "Initial" &&
setdate_and_increment &&
t6300 (for-each-ref): clearly demarcate setup Condense the two-step setup into one step, and give it an appropriate name. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:08 +00:00
git tag -a -m "Tagging at $datestamp" testtag &&
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
git update-ref refs/remotes/origin/master master &&
git remote add origin nowhere &&
git config branch.master.remote origin &&
for-each-ref: accept "%(push)" format Just as we have "%(upstream)" to report the "@{upstream}" for each ref, this patch adds "%(push)" to match "@{push}". It supports the same tracking format modifiers as upstream (because you may want to know, for example, which branches have commits to push). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 04:45:55 +00:00
git config branch.master.merge refs/heads/master &&
git remote add myfork elsewhere &&
git config remote.pushdefault myfork &&
git config push.default current
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom() {
case "$1" in
head) ref=refs/heads/master ;;
tag) ref=refs/tags/testtag ;;
ref-filter: make "%(symref)" atom work with the ':short' modifier 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-10 08:49:42 +00:00
sym) ref=refs/heads/sym ;;
t6300: add more body-parsing tests The current tests don't actually check parsing commit and tag messages that have both a subject and a body (they just have single-line messages). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:43:28 +00:00
*) ref=$1 ;;
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
esac
printf '%s\n' "$3" >expected
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_expect_${4:-success} $PREREQ "basic atom: $1 $2" "
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
git for-each-ref --format='%($2)' $ref >actual &&
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
sanitize_pgp <actual >actual.clean &&
test_cmp expected actual.clean
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
"
ref-filter: add support for %(contents:size) 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-16 12:19:40 +00:00
# Automatically test "contents:size" atom after testing "contents"
if test "$2" = "contents"
then
case $(git cat-file -t "$ref") in
tag)
# We cannot use $3 as it expects sanitize_pgp to run
expect=$(git cat-file tag $ref | tail -n +6 | wc -c) ;;
tree | blob)
expect='' ;;
commit)
expect=$(printf '%s' "$3" | wc -c) ;;
esac
# Leave $expect unquoted to lose possible leading whitespaces
echo $expect >expected
t6300: fix issues related to %(contents:size) 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-31 18:26:07 +00:00
test_expect_${4:-success} $PREREQ "basic atom: $1 contents:size" '
ref-filter: add support for %(contents:size) 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-16 12:19:40 +00:00
git for-each-ref --format="%(contents:size)" "$ref" >actual &&
t6300: fix issues related to %(contents:size) 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-31 18:26:07 +00:00
test_cmp expected actual
ref-filter: add support for %(contents:size) 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-16 12:19:40 +00:00
'
fi
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
}
t6300: abstract away SHA-1-specific constants 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>
2020-02-22 20:17:32 +00:00
hexlen=$(test_oid hexsz)
disklen=$(test_oid disklen)
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head refname refs/heads/master
ref-filter.c: pass empty-string as NULL to atom parsers 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-02 16:10:34 +00:00
test_atom head refname: refs/heads/master
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom head refname:short master
ref-filter: rename the 'strip' option to 'lstrip' 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-10 08:49:46 +00:00
test_atom head refname:lstrip=1 heads/master
test_atom head refname:lstrip=2 master
ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' 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-10 08:49:48 +00:00
test_atom head refname:lstrip=-1 master
test_atom head refname:lstrip=-2 heads/master
ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames 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-10 08:49:49 +00:00
test_atom head refname:rstrip=1 refs/heads
test_atom head refname:rstrip=2 refs
test_atom head refname:rstrip=-1 refs
test_atom head refname:rstrip=-2 refs/heads
ref-filter: resurrect "strip" as a synonym to "lstrip" 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-02-07 19:50:34 +00:00
test_atom head refname:strip=1 heads/master
test_atom head refname:strip=2 master
test_atom head refname:strip=-1 master
test_atom head refname:strip=-2 heads/master
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
test_atom head upstream refs/remotes/origin/master
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom head upstream:short origin/master
ref-filter: rename the 'strip' option to 'lstrip' 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-10 08:49:46 +00:00
test_atom head upstream:lstrip=2 origin/master
ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' 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-10 08:49:48 +00:00
test_atom head upstream:lstrip=-2 origin/master
ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames 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-10 08:49:49 +00:00
test_atom head upstream:rstrip=2 refs/remotes
test_atom head upstream:rstrip=-2 refs/remotes
ref-filter: resurrect "strip" as a synonym to "lstrip" 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-02-07 19:50:34 +00:00
test_atom head upstream:strip=2 origin/master
test_atom head upstream:strip=-2 origin/master
for-each-ref: accept "%(push)" format Just as we have "%(upstream)" to report the "@{upstream}" for each ref, this patch adds "%(push)" to match "@{push}". It supports the same tracking format modifiers as upstream (because you may want to know, for example, which branches have commits to push). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 04:45:55 +00:00
test_atom head push refs/remotes/myfork/master
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom head push:short myfork/master
ref-filter: rename the 'strip' option to 'lstrip' 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-10 08:49:46 +00:00
test_atom head push:lstrip=1 remotes/myfork/master
ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' 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-10 08:49:48 +00:00
test_atom head push:lstrip=-1 master
ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames 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-10 08:49:49 +00:00
test_atom head push:rstrip=1 refs/remotes/myfork
test_atom head push:rstrip=-1 refs
ref-filter: resurrect "strip" as a synonym to "lstrip" 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-02-07 19:50:34 +00:00
test_atom head push:strip=1 remotes/myfork/master
test_atom head push:strip=-1 master
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head objecttype commit
t6300: abstract away SHA-1-specific constants 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>
2020-02-22 20:17:32 +00:00
test_atom head objectsize $((131 + hexlen))
test_atom head objectsize:disk $disklen
test_atom head deltabase $ZERO_OID
t6300 (for-each-ref): don't hardcode SHA-1 hexes Use rev-parse in its place, making it easier for future patches to modify the test script. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:09 +00:00
test_atom head objectname $(git rev-parse refs/heads/master)
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom head objectname:short $(git rev-parse --short refs/heads/master)
ref-filter: modify "%(objectname:short)" to take length 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>
2017-01-10 08:49:37 +00:00
test_atom head objectname:short=1 $(git rev-parse --short=1 refs/heads/master)
test_atom head objectname:short=10 $(git rev-parse --short=10 refs/heads/master)
t6300 (for-each-ref): don't hardcode SHA-1 hexes Use rev-parse in its place, making it easier for future patches to modify the test script. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:09 +00:00
test_atom head tree $(git rev-parse refs/heads/master^{tree})
ref-filter: add `short` modifier to 'tree' atom 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-21 21:41:47 +00:00
test_atom head tree:short $(git rev-parse --short refs/heads/master^{tree})
test_atom head tree:short=1 $(git rev-parse --short=1 refs/heads/master^{tree})
test_atom head tree:short=10 $(git rev-parse --short=10 refs/heads/master^{tree})
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head parent ''
test_atom head numparent 0
test_atom head object ''
test_atom head type ''
for-each-ref: avoid loading objects to print %(objectname) If you ask for-each-ref to print each ref and its object, like: git for-each-ref --format='%(objectname) %(refname)' this should involve little more work than looking at the ref files (and packed-refs) themselves. However, for-each-ref will actually load each object from disk just to print its sha1. For most repositories, this isn't a big deal, but it can be noticeable if you have a large number of refs to print. Here are best-of-five timings for the command above on a repo with ~10K refs: [before] real 0m0.112s user 0m0.092s sys 0m0.016s [after] real 0m0.014s user 0m0.012s sys 0m0.000s This patch checks for %(objectname) and %(objectname:short) before we actually parse the object (and the rest of the code is smart enough to avoid parsing if we have filled all of our placeholders). Note that we can't simply move the objectname parsing code into the early loop. If the "deref" form %(*objectname) is used, then we do need to parse the object in order to peel the tag. So instead of moving the code, we factor it out into a separate function that can be called for both cases. While we're at it, we add some basic tests for the dereferenced placeholders, which were not tested at all before. This helps ensure we didn't regress that case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 06:50:16 +00:00
test_atom head '*objectname' ''
test_atom head '*objecttype' ''
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom head author 'A U Thor <author@example.com> 1151968724 +0200'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head authorname 'A U Thor'
test_atom head authoremail '<author@example.com>'
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom head authoremail:trim 'author@example.com'
test_atom head authoremail:localpart 'author'
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom head authordate 'Tue Jul 4 01:18:44 2006 +0200'
test_atom head committer 'C O Mitter <committer@example.com> 1151968723 +0200'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head committername 'C O Mitter'
test_atom head committeremail '<committer@example.com>'
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom head committeremail:trim 'committer@example.com'
test_atom head committeremail:localpart 'committer'
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom head committerdate 'Tue Jul 4 01:18:43 2006 +0200'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head tag ''
test_atom head tagger ''
test_atom head taggername ''
test_atom head taggeremail ''
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom head taggeremail:trim ''
test_atom head taggeremail:localpart ''
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head taggerdate ''
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom head creator 'C O Mitter <committer@example.com> 1151968723 +0200'
test_atom head creatordate 'Tue Jul 4 01:18:43 2006 +0200'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head subject 'Initial'
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_atom head contents:subject 'Initial'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head body ''
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_atom head contents:body ''
test_atom head contents:signature ''
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom head contents 'Initial
'
for-each-ref: introduce %(HEAD) asterisk marker 'git branch' shows which branch you are currently on with an '*', but 'git for-each-ref' misses this feature. So, extend its format with %(HEAD) for the same effect. Now you can use the following format in for-each-ref: %(HEAD) %(refname:short) to display an asterisk next to the current ref. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:10 +00:00
test_atom head HEAD '*'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag refname refs/tags/testtag
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom tag refname:short testtag
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
test_atom tag upstream ''
for-each-ref: accept "%(push)" format Just as we have "%(upstream)" to report the "@{upstream}" for each ref, this patch adds "%(push)" to match "@{push}". It supports the same tracking format modifiers as upstream (because you may want to know, for example, which branches have commits to push). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 04:45:55 +00:00
test_atom tag push ''
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag objecttype tag
t6300: abstract away SHA-1-specific constants 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>
2020-02-22 20:17:32 +00:00
test_atom tag objectsize $((114 + hexlen))
test_atom tag objectsize:disk $disklen
test_atom tag '*objectsize:disk' $disklen
test_atom tag deltabase $ZERO_OID
test_atom tag '*deltabase' $ZERO_OID
t6300 (for-each-ref): don't hardcode SHA-1 hexes Use rev-parse in its place, making it easier for future patches to modify the test script. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:09 +00:00
test_atom tag objectname $(git rev-parse refs/tags/testtag)
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom tag objectname:short $(git rev-parse --short refs/tags/testtag)
ref-filter: modify "%(objectname:short)" to take length 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>
2017-01-10 08:49:37 +00:00
test_atom head objectname:short=1 $(git rev-parse --short=1 refs/heads/master)
test_atom head objectname:short=10 $(git rev-parse --short=10 refs/heads/master)
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag tree ''
ref-filter: add `short` modifier to 'tree' atom 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-21 21:41:47 +00:00
test_atom tag tree:short ''
test_atom tag tree:short=1 ''
test_atom tag tree:short=10 ''
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag parent ''
test_atom tag numparent ''
t6300 (for-each-ref): don't hardcode SHA-1 hexes Use rev-parse in its place, making it easier for future patches to modify the test script. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:09 +00:00
test_atom tag object $(git rev-parse refs/tags/testtag^0)
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag type 'commit'
t6300: abstract away SHA-1-specific constants 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>
2020-02-22 20:17:32 +00:00
test_atom tag '*objectname' $(git rev-parse refs/tags/testtag^{})
for-each-ref: avoid loading objects to print %(objectname) If you ask for-each-ref to print each ref and its object, like: git for-each-ref --format='%(objectname) %(refname)' this should involve little more work than looking at the ref files (and packed-refs) themselves. However, for-each-ref will actually load each object from disk just to print its sha1. For most repositories, this isn't a big deal, but it can be noticeable if you have a large number of refs to print. Here are best-of-five timings for the command above on a repo with ~10K refs: [before] real 0m0.112s user 0m0.092s sys 0m0.016s [after] real 0m0.014s user 0m0.012s sys 0m0.000s This patch checks for %(objectname) and %(objectname:short) before we actually parse the object (and the rest of the code is smart enough to avoid parsing if we have filled all of our placeholders). Note that we can't simply move the objectname parsing code into the early loop. If the "deref" form %(*objectname) is used, then we do need to parse the object in order to peel the tag. So instead of moving the code, we factor it out into a separate function that can be called for both cases. While we're at it, we add some basic tests for the dereferenced placeholders, which were not tested at all before. This helps ensure we didn't regress that case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 06:50:16 +00:00
test_atom tag '*objecttype' 'commit'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag author ''
test_atom tag authorname ''
test_atom tag authoremail ''
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom tag authoremail:trim ''
test_atom tag authoremail:localpart ''
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag authordate ''
test_atom tag committer ''
test_atom tag committername ''
test_atom tag committeremail ''
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom tag committeremail:trim ''
test_atom tag committeremail:localpart ''
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag committerdate ''
test_atom tag tag 'testtag'
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom tag tagger 'C O Mitter <committer@example.com> 1151968725 +0200'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag taggername 'C O Mitter'
test_atom tag taggeremail '<committer@example.com>'
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom tag taggeremail:trim 'committer@example.com'
test_atom tag taggeremail:localpart 'committer'
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom tag taggerdate 'Tue Jul 4 01:18:45 2006 +0200'
test_atom tag creator 'C O Mitter <committer@example.com> 1151968725 +0200'
test_atom tag creatordate 'Tue Jul 4 01:18:45 2006 +0200'
test_atom tag subject 'Tagging at 1151968727'
test_atom tag contents:subject 'Tagging at 1151968727'
improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 08:08:41 +00:00
test_atom tag body ''
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_atom tag contents:body ''
test_atom tag contents:signature ''
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_atom tag contents 'Tagging at 1151968727
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
for-each-ref: introduce %(HEAD) asterisk marker 'git branch' shows which branch you are currently on with an '*', but 'git for-each-ref' misses this feature. So, extend its format with %(HEAD) for the same effect. Now you can use the following format in for-each-ref: %(HEAD) %(refname:short) to display an asterisk next to the current ref. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:10 +00:00
test_atom tag HEAD ' '
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +00:00
test_expect_success 'Check invalid atoms names are errors' '
tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:29 +00:00
test_must_fail git for-each-ref --format="%(INVALID)" refs/heads
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
test_expect_success 'Check format specifiers are ignored in naming date atoms' '
tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:29 +00:00
git for-each-ref --format="%(authordate)" refs/heads &&
git for-each-ref --format="%(authordate:default) %(authordate)" refs/heads &&
git for-each-ref --format="%(authordate) %(authordate:default)" refs/heads &&
git for-each-ref --format="%(authordate:default) %(authordate:default)" refs/heads
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
test_expect_success 'Check valid format specifiers for date fields' '
tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:29 +00:00
git for-each-ref --format="%(authordate:default)" refs/heads &&
git for-each-ref --format="%(authordate:relative)" refs/heads &&
git for-each-ref --format="%(authordate:short)" refs/heads &&
git for-each-ref --format="%(authordate:local)" refs/heads &&
git for-each-ref --format="%(authordate:iso8601)" refs/heads &&
git for-each-ref --format="%(authordate:rfc2822)" refs/heads
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +00:00
test_expect_success 'Check invalid format specifiers are errors' '
tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:29 +00:00
test_must_fail git for-each-ref --format="%(authordate:INVALID)" refs/heads
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
ref-filter: modify "%(objectname:short)" to take length 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>
2017-01-10 08:49:37 +00:00
test_expect_success 'arguments to %(objectname:short=) must be positive integers' '
test_must_fail git for-each-ref --format="%(objectname:short=0)" &&
test_must_fail git for-each-ref --format="%(objectname:short=-1)" &&
test_must_fail git for-each-ref --format="%(objectname:short=foo)"
'
t6300: introduce test_date() helper 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-09-03 21:48:56 +00:00
test_date () {
f=$1 &&
committer_date=$2 &&
author_date=$3 &&
tagger_date=$4 &&
cat >expected <<-EOF &&
'refs/heads/master' '$committer_date' '$author_date'
'refs/tags/testtag' '$tagger_date'
EOF
(
git for-each-ref --shell \
--format="%(refname) %(committerdate${f:+:$f}) %(authordate${f:+:$f})" \
refs/heads &&
git for-each-ref --shell \
--format="%(refname) %(taggerdate${f:+:$f})" \
refs/tags
) >actual &&
test_cmp expected actual
}
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
test_expect_success 'Check unformatted date fields output' '
t6300: introduce test_date() helper 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-09-03 21:48:56 +00:00
test_date "" \
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
"Tue Jul 4 01:18:43 2006 +0200" \
"Tue Jul 4 01:18:44 2006 +0200" \
"Tue Jul 4 01:18:45 2006 +0200"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
test_expect_success 'Check format "default" formatted date fields output' '
t6300: introduce test_date() helper 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-09-03 21:48:56 +00:00
test_date default \
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
"Tue Jul 4 01:18:43 2006 +0200" \
"Tue Jul 4 01:18:44 2006 +0200" \
"Tue Jul 4 01:18:45 2006 +0200"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
test_expect_success 'Check format "default-local" date fields output' '
test_date default-local "Mon Jul 3 23:18:43 2006" "Mon Jul 3 23:18:44 2006" "Mon Jul 3 23:18:45 2006"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
# Don't know how to do relative check because I can't know when this script
# is going to be run and can't fake the current time to git, and hence can't
# provide expected output. Instead, I'll just make sure that "relative"
# doesn't exit in error
test_expect_success 'Check format "relative" date fields output' '
f=relative &&
(git for-each-ref --shell --format="%(refname) %(committerdate:$f) %(authordate:$f)" refs/heads &&
git for-each-ref --shell --format="%(refname) %(taggerdate:$f)" refs/tags) >actual
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
# We just check that this is the same as "relative" for now.
test_expect_success 'Check format "relative-local" date fields output' '
test_date relative-local \
"$(git for-each-ref --format="%(committerdate:relative)" refs/heads)" \
"$(git for-each-ref --format="%(authordate:relative)" refs/heads)" \
"$(git for-each-ref --format="%(taggerdate:relative)" refs/tags)"
'
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
test_expect_success 'Check format "short" date fields output' '
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_date short 2006-07-04 2006-07-04 2006-07-04
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
test_expect_success 'Check format "short-local" date fields output' '
test_date short-local 2006-07-03 2006-07-03 2006-07-03
'
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
test_expect_success 'Check format "local" date fields output' '
t6300: introduce test_date() helper 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-09-03 21:48:56 +00:00
test_date local \
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
"Mon Jul 3 23:18:43 2006" \
"Mon Jul 3 23:18:44 2006" \
"Mon Jul 3 23:18:45 2006"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
test_expect_success 'Check format "iso8601" date fields output' '
t6300: introduce test_date() helper 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-09-03 21:48:56 +00:00
test_date iso8601 \
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
"2006-07-04 01:18:43 +0200" \
"2006-07-04 01:18:44 +0200" \
"2006-07-04 01:18:45 +0200"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
test_expect_success 'Check format "iso8601-local" date fields output' '
test_date iso8601-local "2006-07-03 23:18:43 +0000" "2006-07-03 23:18:44 +0000" "2006-07-03 23:18:45 +0000"
'
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
test_expect_success 'Check format "rfc2822" date fields output' '
t6300: introduce test_date() helper 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-09-03 21:48:56 +00:00
test_date rfc2822 \
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
"Tue, 4 Jul 2006 01:18:43 +0200" \
"Tue, 4 Jul 2006 01:18:44 +0200" \
"Tue, 4 Jul 2006 01:18:45 +0200"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
test_expect_success 'Check format "rfc2822-local" date fields output' '
test_date rfc2822-local "Mon, 3 Jul 2006 23:18:43 +0000" "Mon, 3 Jul 2006 23:18:44 +0000" "Mon, 3 Jul 2006 23:18:45 +0000"
'
t6300: add test for "raw" date format Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:48:57 +00:00
test_expect_success 'Check format "raw" date fields output' '
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
test_date raw "1151968723 +0200" "1151968724 +0200" "1151968725 +0200"
t6300: add test for "raw" date format Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:48:57 +00:00
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
test_expect_success 'Check format "raw-local" date fields output' '
test_date raw-local "1151968723 +0000" "1151968724 +0000" "1151968725 +0000"
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
'
introduce "format" date-mode This feeds the format directly to strftime. Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:45 +00:00
test_expect_success 'Check format of strftime date fields' '
t6300: make UTC and local dates different 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-03 21:49:00 +00:00
echo "my date is 2006-07-04" >expected &&
introduce "format" date-mode This feeds the format directly to strftime. Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:45 +00:00
git for-each-ref \
--format="%(authordate:format:my date is %Y-%m-%d)" \
refs/heads >actual &&
test_cmp expected actual
'
t6300: add tests for "-local" date formats Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 21:49:01 +00:00
test_expect_success 'Check format of strftime-local date fields' '
echo "my date is 2006-07-03" >expected &&
git for-each-ref \
--format="%(authordate:format-local:my date is %Y-%m-%d)" \
refs/heads >actual &&
test_cmp expected actual
'
strbuf: make strbuf_addftime more robust 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>
2015-06-30 13:26:53 +00:00
test_expect_success 'exercise strftime with odd fields' '
echo >expected &&
git for-each-ref --format="%(authordate:format:)" refs/heads >actual &&
test_cmp expected actual &&
t: switch $_z40 to $ZERO_OID 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-05-13 02:24:13 +00:00
long="long format -- $ZERO_OID$ZERO_OID$ZERO_OID$ZERO_OID$ZERO_OID$ZERO_OID$ZERO_OID" &&
strbuf: make strbuf_addftime more robust 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>
2015-06-30 13:26:53 +00:00
echo $long >expected &&
git for-each-ref --format="%(authordate:format:$long)" refs/heads >actual &&
test_cmp expected actual
'
for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 16:47:54 +00:00
cat >expected <<\EOF
refs/heads/master
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
refs/remotes/origin/master
for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 16:47:54 +00:00
refs/tags/testtag
EOF
test_expect_success 'Verify ascending sort' '
tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:29 +00:00
git for-each-ref --format="%(refname)" --sort=refname >actual &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp expected actual
for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 16:47:54 +00:00
'
cat >expected <<\EOF
refs/tags/testtag
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
refs/remotes/origin/master
for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 16:47:54 +00:00
refs/heads/master
EOF
test_expect_success 'Verify descending sort' '
tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:29 +00:00
git for-each-ref --format="%(refname)" --sort=-refname >actual &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp expected actual
ref-filter.c: find disjoint pattern prefixes 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-06-26 22:41:48 +00:00
'
cat >expected <<\EOF
refs/tags/testtag
refs/tags/testtag-2
EOF
test_expect_success 'exercise patterns with prefixes' '
git tag testtag-2 &&
test_when_finished "git tag -d testtag-2" &&
git for-each-ref --format="%(refname)" \
refs/tags/testtag refs/tags/testtag-2 >actual &&
test_cmp expected actual
'
cat >expected <<\EOF
refs/tags/testtag
refs/tags/testtag-2
EOF
test_expect_success 'exercise glob patterns with prefixes' '
git tag testtag-2 &&
test_when_finished "git tag -d testtag-2" &&
git for-each-ref --format="%(refname)" \
refs/tags/testtag "refs/tags/testtag-*" >actual &&
test_cmp expected actual
for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 16:47:54 +00:00
'
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
cat >expected <<\EOF
'refs/heads/master'
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
'refs/remotes/origin/master'
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
'refs/tags/testtag'
EOF
test_expect_success 'Quoting style: shell' '
git for-each-ref --shell --format="%(refname)" >actual &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp expected actual
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
'
test_expect_success 'Quoting style: perl' '
git for-each-ref --perl --format="%(refname)" >actual &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp expected actual
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
'
test_expect_success 'Quoting style: python' '
git for-each-ref --python --format="%(refname)" >actual &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp expected actual
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
'
cat >expected <<\EOF
"refs/heads/master"
for-each-ref: add "upstream" format field The logic for determining the upstream ref of a branch is somewhat complex to perform in a shell script. This patch provides a plumbing mechanism for scripts to access the C logic used internally by git-status, git-branch, etc. For example: $ git for-each-ref \ --format='%(refname:short) %(upstream:short)' \ refs/heads/ master origin/master Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 07:09:39 +00:00
"refs/remotes/origin/master"
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
"refs/tags/testtag"
EOF
test_expect_success 'Quoting style: tcl' '
git for-each-ref --tcl --format="%(refname)" >actual &&
tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 05:28:56 +00:00
test_cmp expected actual
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
'
for i in "--perl --shell" "-s --python" "--python --tcl" "--tcl --perl"; do
test_expect_success "more than one quoting style: $i" "
t6300-for-each-ref: fix "more than one quoting style" tests '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>
2018-02-13 00:36:01 +00:00
test_must_fail git for-each-ref $i 2>err &&
grep '^error: more than one quoting style' err
for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 12:24:39 +00:00
"
done
for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 16:47:54 +00:00
for-each-ref: introduce %(upstream:track[short]) Introduce %(upstream:track) to display "[ahead M, behind N]" and %(upstream:trackshort) to display "=", ">", "<", or "<>" appropriately (inspired by contrib/completion/git-prompt.sh). Now you can use the following format in for-each-ref: %(refname:short)%(upstream:trackshort) to display refs with terse tracking information. Note that :track and :trackshort only work with "upstream", and error out when used with anything else. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:11 +00:00
test_expect_success 'setup for upstream:track[short]' '
test_commit two
'
t6300: use test_atom for some un-modern tests 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>
2016-01-24 23:08:18 +00:00
test_atom head upstream:track '[ahead 1]'
test_atom head upstream:trackshort '>'
ref-filter: add support for %(upstream:track,nobracket) 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-10 08:49:41 +00:00
test_atom head upstream:track,nobracket 'ahead 1'
test_atom head upstream:nobracket,track 'ahead 1'
ref-filter: use correct branch for %(push:track) 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>
2019-04-16 12:16:46 +00:00
test_expect_success 'setup for push:track[short]' '
test_commit third &&
git update-ref refs/remotes/myfork/master master &&
git reset master~1
'
test_atom head push:track '[behind 1]'
test_atom head push:trackshort '<'
for-each-ref: introduce %(upstream:track[short]) Introduce %(upstream:track) to display "[ahead M, behind N]" and %(upstream:trackshort) to display "=", ">", "<", or "<>" appropriately (inspired by contrib/completion/git-prompt.sh). Now you can use the following format in for-each-ref: %(refname:short)%(upstream:trackshort) to display refs with terse tracking information. Note that :track and :trackshort only work with "upstream", and error out when used with anything else. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:11 +00:00
test_expect_success 'Check that :track[short] cannot be used with other atoms' '
test_must_fail git for-each-ref --format="%(refname:track)" 2>/dev/null &&
test_must_fail git for-each-ref --format="%(refname:trackshort)" 2>/dev/null
'
for-each-ref: always check stat_tracking_info()'s return value The code handling %(upstream:track) and %(upstream:trackshort) assumed that it always had a valid branch that had been sanitized earlier in populate_value(), and thus did not check the return value of the call to stat_tracking_info(). While there is indeed some sanitization code that basically corresponds to stat_tracking_info() returning 0 (no base branch set), the function can also return -1 when the base branch did exist but has since then been deleted. In this case, num_ours and num_theirs had undefined values and a call to `git for-each-ref --format="%(upstream:track)"` could print spurious values such as [behind -111794512] [ahead 38881640, behind 5103867] even for repositories with one single commit. Verify stat_tracking_info()'s return value and do not print anything if it returns -1. This behavior also matches the documentation ("has no effect if the ref does not have tracking information associated with it"). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-05 09:58:55 +00:00
test_expect_success 'Check that :track[short] works when upstream is invalid' '
cat >expected <<-\EOF &&
ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams 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-10 08:49:40 +00:00
[gone]
for-each-ref: always check stat_tracking_info()'s return value The code handling %(upstream:track) and %(upstream:trackshort) assumed that it always had a valid branch that had been sanitized earlier in populate_value(), and thus did not check the return value of the call to stat_tracking_info(). While there is indeed some sanitization code that basically corresponds to stat_tracking_info() returning 0 (no base branch set), the function can also return -1 when the base branch did exist but has since then been deleted. In this case, num_ours and num_theirs had undefined values and a call to `git for-each-ref --format="%(upstream:track)"` could print spurious values such as [behind -111794512] [ahead 38881640, behind 5103867] even for repositories with one single commit. Verify stat_tracking_info()'s return value and do not print anything if it returns -1. This behavior also matches the documentation ("has no effect if the ref does not have tracking information associated with it"). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-05 09:58:55 +00:00
EOF
test_when_finished "git config branch.master.merge refs/heads/master" &&
git config branch.master.merge refs/heads/does-not-exist &&
git for-each-ref \
--format="%(upstream:track)$LF%(upstream:trackshort)" \
refs/heads >actual &&
test_cmp expected actual
for-each-ref: accept "%(push)" format Just as we have "%(upstream)" to report the "@{upstream}" for each ref, this patch adds "%(push)" to match "@{push}". It supports the same tracking format modifiers as upstream (because you may want to know, for example, which branches have commits to push). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21 04:45:55 +00:00
'
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 21:16:23 +00:00
test_expect_success 'Check for invalid refname format' '
test_must_fail git for-each-ref --format="%(refname:INVALID)"
'
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
test_expect_success 'set up color tests' '
cat >expected.color <<-EOF &&
$(git rev-parse --short refs/heads/master) <GREEN>master<RESET>
ref-filter: use correct branch for %(push:track) 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>
2019-04-16 12:16:46 +00:00
$(git rev-parse --short refs/remotes/myfork/master) <GREEN>myfork/master<RESET>
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
$(git rev-parse --short refs/remotes/origin/master) <GREEN>origin/master<RESET>
$(git rev-parse --short refs/tags/testtag) <GREEN>testtag<RESET>
ref-filter: use correct branch for %(push:track) 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>
2019-04-16 12:16:46 +00:00
$(git rev-parse --short refs/tags/third) <GREEN>third<RESET>
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
$(git rev-parse --short refs/tags/two) <GREEN>two<RESET>
EOF
sed "s/<[^>]*>//g" <expected.color >expected.bare &&
color_format="%(objectname:short) %(color:green)%(refname:short)"
'
for-each-ref: introduce %(color:...) for color Enhance 'git for-each-ref' with color formatting options. You can now use the following format in for-each-ref: %(color:green)%(refname:short)%(color:reset) where color names are described in color.branch.*. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:12 +00:00
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
test_expect_success TTY '%(color) shows color with a tty' '
test-terminal: set TERM=vt100 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-03 13:39:34 +00:00
test_terminal git for-each-ref --format="$color_format" >actual.raw &&
t: use test_decode_color rather than literal ANSI codes 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-07-13 14:58:41 +00:00
test_decode_color <actual.raw >actual &&
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
test_cmp expected.color actual
'
test_expect_success '%(color) does not show color without tty' '
TERM=vt100 git for-each-ref --format="$color_format" >actual &&
test_cmp expected.bare actual
'
provide --color option for all ref-filter users 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-03 13:45:47 +00:00
test_expect_success '--color can override tty check' '
git for-each-ref --color --format="$color_format" >actual.raw &&
ref-filter: consult want_color() before emitting colors 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-13 15:09:32 +00:00
test_decode_color <actual.raw >actual &&
test_cmp expected.color actual
for-each-ref: introduce %(color:...) for color Enhance 'git for-each-ref' with color formatting options. You can now use the following format in for-each-ref: %(color:green)%(refname:short)%(color:reset) where color names are described in color.branch.*. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 17:39:12 +00:00
'
tag: respect color.ui config 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-13 17:26:02 +00:00
test_expect_success 'color.ui=always does not override tty check' '
git -c color.ui=always for-each-ref --format="$color_format" >actual &&
test_cmp expected.bare actual
'
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 21:16:23 +00:00
cat >expected <<\EOF
heads/master
for-each-ref: utilize core.warnAmbiguousRefs for :short-format core.warnAmbiguousRefs is used to select strict mode for the abbreviation for the ":short" format specifier of "refname" and "upstream". In strict mode, the abbreviated ref will never trigger the 'warn_ambiguous_refs' warning. I.e. for these refs: refs/heads/xyzzy refs/tags/xyzzy the abbreviated forms are: heads/xyzzy tags/xyzzy Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13 10:25:47 +00:00
tags/master
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 21:16:23 +00:00
EOF
for-each-ref: utilize core.warnAmbiguousRefs for :short-format core.warnAmbiguousRefs is used to select strict mode for the abbreviation for the ":short" format specifier of "refname" and "upstream". In strict mode, the abbreviated ref will never trigger the 'warn_ambiguous_refs' warning. I.e. for these refs: refs/heads/xyzzy refs/tags/xyzzy the abbreviated forms are: heads/xyzzy tags/xyzzy Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13 10:25:47 +00:00
test_expect_success 'Check ambiguous head and tag refs (strict)' '
git config --bool core.warnambiguousrefs true &&
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 21:16:23 +00:00
git checkout -b newtag &&
echo "Using $datestamp" > one &&
git add one &&
git commit -m "Branch" &&
setdate_and_increment &&
git tag -m "Tagging at $datestamp" master &&
git for-each-ref --format "%(refname:short)" refs/heads/master refs/tags/master >actual &&
test_cmp expected actual
'
for-each-ref: utilize core.warnAmbiguousRefs for :short-format core.warnAmbiguousRefs is used to select strict mode for the abbreviation for the ":short" format specifier of "refname" and "upstream". In strict mode, the abbreviated ref will never trigger the 'warn_ambiguous_refs' warning. I.e. for these refs: refs/heads/xyzzy refs/tags/xyzzy the abbreviated forms are: heads/xyzzy tags/xyzzy Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13 10:25:47 +00:00
cat >expected <<\EOF
heads/master
master
EOF
test_expect_success 'Check ambiguous head and tag refs (loose)' '
git config --bool core.warnambiguousrefs false &&
git for-each-ref --format "%(refname:short)" refs/heads/master refs/tags/master >actual &&
test_cmp expected actual
'
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 21:16:23 +00:00
cat >expected <<\EOF
heads/ambiguous
ambiguous
EOF
for-each-ref: utilize core.warnAmbiguousRefs for :short-format core.warnAmbiguousRefs is used to select strict mode for the abbreviation for the ":short" format specifier of "refname" and "upstream". In strict mode, the abbreviated ref will never trigger the 'warn_ambiguous_refs' warning. I.e. for these refs: refs/heads/xyzzy refs/tags/xyzzy the abbreviated forms are: heads/xyzzy tags/xyzzy Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13 10:25:47 +00:00
test_expect_success 'Check ambiguous head and tag refs II (loose)' '
for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 21:16:23 +00:00
git checkout master &&
git tag ambiguous testtag^0 &&
git branch ambiguous testtag^0 &&
git for-each-ref --format "%(refname:short)" refs/heads/ambiguous refs/tags/ambiguous >actual &&
test_cmp expected actual
'
ref-filter: initialize empty name or email fields 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-08-17 21:51:07 +00:00
test_expect_success 'create tag without tagger' '
git tag -a -m "Broken tag" taggerless &&
git tag -f taggerless $(git cat-file tag taggerless |
sed -e "/^tagger /d" |
git hash-object --stdin -w -t tag)
'
test_atom refs/tags/taggerless type 'commit'
test_atom refs/tags/taggerless tag 'taggerless'
test_atom refs/tags/taggerless tagger ''
test_atom refs/tags/taggerless taggername ''
test_atom refs/tags/taggerless taggeremail ''
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom refs/tags/taggerless taggeremail:trim ''
test_atom refs/tags/taggerless taggeremail:localpart ''
ref-filter: initialize empty name or email fields 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-08-17 21:51:07 +00:00
test_atom refs/tags/taggerless taggerdate ''
test_atom refs/tags/taggerless committer ''
test_atom refs/tags/taggerless committername ''
test_atom refs/tags/taggerless committeremail ''
ref-filter: support different email formats 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-21 21:41:43 +00:00
test_atom refs/tags/taggerless committeremail:trim ''
test_atom refs/tags/taggerless committeremail:localpart ''
ref-filter: initialize empty name or email fields 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-08-17 21:51:07 +00:00
test_atom refs/tags/taggerless committerdate ''
test_atom refs/tags/taggerless subject 'Broken tag'
for-each-ref: cope with tags with incomplete lines If you have a tag with a single, incomplete line as its payload, asking git-for-each-ref for its %(body) element accessed a NULL pointer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-20 19:29:27 +00:00
test_expect_success 'an unusual tag with an incomplete line' '
git tag -m "bogo" bogo &&
bogo=$(git cat-file tag bogo) &&
bogo=$(printf "%s" "$bogo" | git mktag) &&
git tag -f bogo "$bogo" &&
git for-each-ref --format "%(body)" refs/tags/bogo
'
t6300: add more body-parsing tests The current tests don't actually check parsing commit and tag messages that have both a subject and a body (they just have single-line messages). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:43:28 +00:00
test_expect_success 'create tag with subject and body content' '
cat >>msg <<-\EOF &&
the subject line
first body line
second body line
EOF
git tag -F msg subject-body
'
test_atom refs/tags/subject-body subject 'the subject line'
test_atom refs/tags/subject-body body 'first body line
second body line
'
test_atom refs/tags/subject-body contents 'the subject line
first body line
second body line
'
for-each-ref: handle multiline subjects like --pretty Generally the format of a git tag or commit message is: subject body body body body body body However, we occasionally see multiline subjects like: subject with multiple lines body body body body body body The rest of git treats these multiline subjects as something to be concatenated and shown as a single line (e.g., "git log --pretty=format:%s" will do so since f53bd74). For consistency, for-each-ref should do the same with its "%(subject)". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:44:56 +00:00
test_expect_success 'create tag with multiline subject' '
cat >msg <<-\EOF &&
first subject line
second subject line
first body line
second body line
EOF
git tag -F msg multiline
'
test_atom refs/tags/multiline subject 'first subject line second subject line'
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_atom refs/tags/multiline contents:subject 'first subject line second subject line'
for-each-ref: handle multiline subjects like --pretty Generally the format of a git tag or commit message is: subject body body body body body body However, we occasionally see multiline subjects like: subject with multiple lines body body body body body body The rest of git treats these multiline subjects as something to be concatenated and shown as a single line (e.g., "git log --pretty=format:%s" will do so since f53bd74). For consistency, for-each-ref should do the same with its "%(subject)". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:44:56 +00:00
test_atom refs/tags/multiline body 'first body line
second body line
'
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_atom refs/tags/multiline contents:body 'first body line
second body line
'
test_atom refs/tags/multiline contents:signature ''
for-each-ref: handle multiline subjects like --pretty Generally the format of a git tag or commit message is: subject body body body body body body However, we occasionally see multiline subjects like: subject with multiple lines body body body body body body The rest of git treats these multiline subjects as something to be concatenated and shown as a single line (e.g., "git log --pretty=format:%s" will do so since f53bd74). For consistency, for-each-ref should do the same with its "%(subject)". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:44:56 +00:00
test_atom refs/tags/multiline contents 'first subject line
second subject line
first body line
second body line
'
for-each-ref: add split message parts to %(contents:*). The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-07 17:46:08 +00:00
test_expect_success GPG 'create signed tags' '
git tag -s -m "" signed-empty &&
git tag -s -m "subject line" signed-short &&
cat >msg <<-\EOF &&
subject line
body contents
EOF
git tag -s -F msg signed-long
'
sig='-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
'
PREREQ=GPG
test_atom refs/tags/signed-empty subject ''
test_atom refs/tags/signed-empty contents:subject ''
test_atom refs/tags/signed-empty body "$sig"
test_atom refs/tags/signed-empty contents:body ''
test_atom refs/tags/signed-empty contents:signature "$sig"
test_atom refs/tags/signed-empty contents "$sig"
test_atom refs/tags/signed-short subject 'subject line'
test_atom refs/tags/signed-short contents:subject 'subject line'
test_atom refs/tags/signed-short body "$sig"
test_atom refs/tags/signed-short contents:body ''
test_atom refs/tags/signed-short contents:signature "$sig"
test_atom refs/tags/signed-short contents "subject line
$sig"
test_atom refs/tags/signed-long subject 'subject line'
test_atom refs/tags/signed-long contents:subject 'subject line'
test_atom refs/tags/signed-long body "body contents
$sig"
test_atom refs/tags/signed-long contents:body 'body contents
'
test_atom refs/tags/signed-long contents:signature "$sig"
test_atom refs/tags/signed-long contents "subject line
body contents
$sig"
t6300: test refs pointing to tree and blob 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-07-10 16:47:38 +00:00
test_expect_success 'set up refs pointing to tree and blob' '
git update-ref refs/mytrees/first refs/heads/master^{tree} &&
git update-ref refs/myblobs/first refs/heads/master:one
'
test_atom refs/mytrees/first subject ""
test_atom refs/mytrees/first contents:subject ""
test_atom refs/mytrees/first body ""
test_atom refs/mytrees/first contents:body ""
test_atom refs/mytrees/first contents:signature ""
test_atom refs/mytrees/first contents ""
test_atom refs/myblobs/first subject ""
test_atom refs/myblobs/first contents:subject ""
test_atom refs/myblobs/first body ""
test_atom refs/myblobs/first contents:body ""
test_atom refs/myblobs/first contents:signature ""
test_atom refs/myblobs/first contents ""
ref-filter: apply fallback refname sort only after all user sorts 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-03 09:13:09 +00:00
test_expect_success 'set up multiple-sort tags' '
for when in 100000 200000
do
for email in user1 user2
do
for ref in ref1 ref2
do
GIT_COMMITTER_DATE="@$when +0000" \
GIT_COMMITTER_EMAIL="$email@example.com" \
git tag -m "tag $ref-$when-$email" \
multi-$ref-$when-$email || return 1
done
done
done
'
t6300: test sort with multiple keys Documentation of git-for-each-ref says that --sort=<key> option can be used multiple times, in which case the last key becomes the primary key. However this functionality was never checked in test suite and is currently broken. This commit adds appropriate test in preparation for fix. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 07:46:06 +00:00
for-each-ref: Fix sort with multiple keys The linked list describing sort options was not correctly set up in opt_parse_sort. In the result, contrary to the documentation, only the last of multiple --sort options to git-for-each-ref was taken into account. This commit fixes it. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 07:47:26 +00:00
test_expect_success 'Verify sort with multiple keys' '
ref-filter: apply fallback refname sort only after all user sorts 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-03 09:13:09 +00:00
cat >expected <<-\EOF &&
100000 <user1@example.com> refs/tags/multi-ref2-100000-user1
100000 <user1@example.com> refs/tags/multi-ref1-100000-user1
100000 <user2@example.com> refs/tags/multi-ref2-100000-user2
100000 <user2@example.com> refs/tags/multi-ref1-100000-user2
200000 <user1@example.com> refs/tags/multi-ref2-200000-user1
200000 <user1@example.com> refs/tags/multi-ref1-200000-user1
200000 <user2@example.com> refs/tags/multi-ref2-200000-user2
200000 <user2@example.com> refs/tags/multi-ref1-200000-user2
EOF
git for-each-ref \
--format="%(taggerdate:unix) %(taggeremail) %(refname)" \
--sort=-refname \
--sort=taggeremail \
--sort=taggerdate \
"refs/tags/multi-*" >actual &&
t6300: test sort with multiple keys Documentation of git-for-each-ref says that --sort=<key> option can be used multiple times, in which case the last key becomes the primary key. However this functionality was never checked in test suite and is currently broken. This commit adds appropriate test in preparation for fix. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 07:46:06 +00:00
test_cmp expected actual
'
for-each-ref: do not segv with %(HEAD) on an unborn branch 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-11-18 23:21:12 +00:00
ref-filter: apply fallback refname sort only after all user sorts 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-03 09:13:09 +00:00
test_expect_success 'equivalent sorts fall back on refname' '
cat >expected <<-\EOF &&
100000 <user1@example.com> refs/tags/multi-ref1-100000-user1
100000 <user2@example.com> refs/tags/multi-ref1-100000-user2
100000 <user1@example.com> refs/tags/multi-ref2-100000-user1
100000 <user2@example.com> refs/tags/multi-ref2-100000-user2
200000 <user1@example.com> refs/tags/multi-ref1-200000-user1
200000 <user2@example.com> refs/tags/multi-ref1-200000-user2
200000 <user1@example.com> refs/tags/multi-ref2-200000-user1
200000 <user2@example.com> refs/tags/multi-ref2-200000-user2
EOF
git for-each-ref \
--format="%(taggerdate:unix) %(taggeremail) %(refname)" \
--sort=taggerdate \
"refs/tags/multi-*" >actual &&
test_cmp expected actual
'
ref-filter: make "%(symref)" atom work with the ':short' modifier 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-10 08:49:42 +00:00
for-each-ref: do not segv with %(HEAD) on an unborn branch 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-11-18 23:21:12 +00:00
test_expect_success 'do not dereference NULL upon %(HEAD) on unborn branch' '
test_when_finished "git checkout master" &&
git for-each-ref --format="%(HEAD) %(refname:short)" refs/heads/ >actual &&
sed -e "s/^\* / /" actual >expect &&
t6300: avoid creating refs/heads/HEAD 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-27 09:29:31 +00:00
git checkout --orphan orphaned-branch &&
for-each-ref: do not segv with %(HEAD) on an unborn branch 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-11-18 23:21:12 +00:00
git for-each-ref --format="%(HEAD) %(refname:short)" refs/heads/ >actual &&
test_cmp expect actual
'
ref-filter: add support to display trailers as part of contents 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-19 00:58:15 +00:00
cat >trailers <<EOF
Reviewed-by: A U Thor <author@example.com>
Signed-off-by: A U Thor <author@example.com>
t6300: refactor %(trailers) tests 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-10-02 05:25:22 +00:00
[ v2 updated patch description ]
Acked-by: A U Thor
<author@example.com>
ref-filter: add support to display trailers as part of contents 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-19 00:58:15 +00:00
EOF
ref-filter.c: use trailer_opts to format trailers 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-02 05:25:23 +00:00
unfold () {
perl -0pe 's/\n\s+/ /g'
}
t6300: refactor %(trailers) tests 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-10-02 05:25:22 +00:00
test_expect_success 'set up trailers for next test' '
ref-filter: add support to display trailers as part of contents 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-19 00:58:15 +00:00
echo "Some contents" > two &&
git add two &&
t6300: refactor %(trailers) tests 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-10-02 05:25:22 +00:00
git commit -F - <<-EOF
ref-filter: add support to display trailers as part of contents 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-19 00:58:15 +00:00
trailers: this commit message has trailers
Some message contents
$(cat trailers)
EOF
t6300: refactor %(trailers) tests 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-10-02 05:25:22 +00:00
'
ref-filter.c: use trailer_opts to format trailers 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-02 05:25:23 +00:00
test_expect_success '%(trailers:unfold) unfolds trailers' '
git for-each-ref --format="%(trailers:unfold)" refs/heads/master >actual &&
{
unfold <trailers
echo
} >expect &&
test_cmp expect actual
'
test_expect_success '%(trailers:only) shows only "key: value" trailers' '
git for-each-ref --format="%(trailers:only)" refs/heads/master >actual &&
{
grep -v patch.description <trailers &&
echo
} >expect &&
test_cmp expect actual
'
test_expect_success '%(trailers:only) and %(trailers:unfold) work together' '
git for-each-ref --format="%(trailers:only,unfold)" refs/heads/master >actual &&
git for-each-ref --format="%(trailers:unfold,only)" refs/heads/master >reverse &&
test_cmp actual reverse &&
{
grep -v patch.description <trailers | unfold &&
echo
} >expect &&
test_cmp expect actual
'
ref-filter.c: parse trailers arguments with %(contents) atom 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-02 05:25:24 +00:00
test_expect_success '%(contents:trailers:unfold) unfolds trailers' '
git for-each-ref --format="%(contents:trailers:unfold)" refs/heads/master >actual &&
{
unfold <trailers
echo
} >expect &&
test_cmp expect actual
'
test_expect_success '%(contents:trailers:only) shows only "key: value" trailers' '
git for-each-ref --format="%(contents:trailers:only)" refs/heads/master >actual &&
{
grep -v patch.description <trailers &&
echo
} >expect &&
test_cmp expect actual
'
test_expect_success '%(contents:trailers:only) and %(contents:trailers:unfold) work together' '
git for-each-ref --format="%(contents:trailers:only,unfold)" refs/heads/master >actual &&
git for-each-ref --format="%(contents:trailers:unfold,only)" refs/heads/master >reverse &&
test_cmp actual reverse &&
{
grep -v patch.description <trailers | unfold &&
echo
} >expect &&
test_cmp expect actual
'
ref-filter.c: use trailer_opts to format trailers 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-02 05:25:23 +00:00
test_expect_success '%(trailers) rejects unknown trailers arguments' '
# error message cannot be checked under i18n
cat >expect <<-EOF &&
fatal: unknown %(trailers) argument: unsupported
EOF
test_must_fail git for-each-ref --format="%(trailers:unsupported)" 2>actual &&
test_i18ncmp expect actual
'
ref-filter.c: parse trailers arguments with %(contents) atom 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-02 05:25:24 +00:00
test_expect_success '%(contents:trailers) rejects unknown trailers arguments' '
# error message cannot be checked under i18n
cat >expect <<-EOF &&
fatal: unknown %(trailers) argument: unsupported
EOF
test_must_fail git for-each-ref --format="%(contents:trailers:unsupported)" 2>actual &&
test_i18ncmp expect actual
'
t6300: refactor %(trailers) tests 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-10-02 05:25:22 +00:00
test_expect_success 'basic atom: head contents:trailers' '
ref-filter: add support to display trailers as part of contents 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-19 00:58:15 +00:00
git for-each-ref --format="%(contents:trailers)" refs/heads/master >actual &&
sanitize_pgp <actual >actual.clean &&
# git for-each-ref ends with a blank line
cat >expect <<-EOF &&
$(cat trailers)
EOF
test_cmp expect actual.clean
'
pretty, ref-filter: format %(trailers) with no_divider option 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-08-23 00:50:17 +00:00
test_expect_success 'trailer parsing not fooled by --- line' '
git commit --allow-empty -F - <<-\EOF &&
this is the subject
This is the body. The message has a "---" line which would confuse a
message+patch parser. But here we know we have only a commit message,
so we get it right.
trailer: wrong
---
This is more body.
trailer: right
EOF
{
echo "trailer: right" &&
echo
} >expect &&
git for-each-ref --format="%(trailers)" refs/heads/master >actual &&
test_cmp expect actual
'
ref-filter: make "%(symref)" atom work with the ':short' modifier 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-10 08:49:42 +00:00
test_expect_success 'Add symbolic ref for the following tests' '
git symbolic-ref refs/heads/sym refs/heads/master
'
cat >expected <<EOF
refs/heads/master
EOF
test_expect_success 'Verify usage of %(symref) atom' '
git for-each-ref --format="%(symref)" refs/heads/sym >actual &&
test_cmp expected actual
'
cat >expected <<EOF
heads/master
EOF
test_expect_success 'Verify usage of %(symref:short) atom' '
git for-each-ref --format="%(symref:short)" refs/heads/sym >actual &&
test_cmp expected actual
'
ref-filter: introduce refname_atom_parser() 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-10 08:49:44 +00:00
cat >expected <<EOF
master
ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' 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-10 08:49:48 +00:00
heads/master
ref-filter: introduce refname_atom_parser() 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-10 08:49:44 +00:00
EOF
ref-filter: rename the 'strip' option to 'lstrip' 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-10 08:49:46 +00:00
test_expect_success 'Verify usage of %(symref:lstrip) atom' '
git for-each-ref --format="%(symref:lstrip=2)" refs/heads/sym > actual &&
ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' 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-10 08:49:48 +00:00
git for-each-ref --format="%(symref:lstrip=-2)" refs/heads/sym >> actual &&
ref-filter: resurrect "strip" as a synonym to "lstrip" 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-02-07 19:50:34 +00:00
test_cmp expected actual &&
git for-each-ref --format="%(symref:strip=2)" refs/heads/sym > actual &&
git for-each-ref --format="%(symref:strip=-2)" refs/heads/sym >> actual &&
ref-filter: introduce refname_atom_parser() 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-10 08:49:44 +00:00
test_cmp expected actual
'
ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames 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-10 08:49:49 +00:00
cat >expected <<EOF
refs
refs/heads
EOF
test_expect_success 'Verify usage of %(symref:rstrip) atom' '
git for-each-ref --format="%(symref:rstrip=2)" refs/heads/sym > actual &&
git for-each-ref --format="%(symref:rstrip=-2)" refs/heads/sym >> actual &&
test_cmp expected actual
'
for-each-ref: test :remotename and :remoteref 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-11-07 16:31:14 +00:00
test_expect_success ':remotename and :remoteref' '
git init remote-tests &&
(
cd remote-tests &&
test_commit initial &&
git remote add from fifth.coffee:blub &&
git config branch.master.remote from &&
git config branch.master.merge refs/heads/stable &&
git remote add to southridge.audio:repo &&
git config remote.to.push "refs/heads/*:refs/heads/pushed/*" &&
git config branch.master.pushRemote to &&
for pair in "%(upstream)=refs/remotes/from/stable" \
"%(upstream:remotename)=from" \
"%(upstream:remoteref)=refs/heads/stable" \
"%(push)=refs/remotes/to/pushed/master" \
"%(push:remotename)=to" \
"%(push:remoteref)=refs/heads/pushed/master"
do
echo "${pair#*=}" >expect &&
git for-each-ref --format="${pair%=*}" \
refs/heads/master >actual &&
test_cmp expect actual
done &&
git branch push-simple &&
git config branch.push-simple.pushRemote from &&
actual="$(git for-each-ref \
--format="%(push:remotename),%(push:remoteref)" \
refs/heads/push-simple)" &&
test from, = "$actual"
)
'
ref-filter: avoid backend filtering with --ignore-case 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-02 21:12:42 +00:00
test_expect_success 'for-each-ref --ignore-case ignores case' '
t6300: add a test for --ignore-case 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-07-02 21:11:23 +00:00
git for-each-ref --format="%(refname)" refs/heads/MASTER >actual &&
tests: make use of the test_must_be_empty function 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-27 17:48:11 +00:00
test_must_be_empty actual &&
t6300: add a test for --ignore-case 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-07-02 21:11:23 +00:00
echo refs/heads/master >expect &&
git for-each-ref --format="%(refname)" --ignore-case \
refs/heads/MASTER >actual &&
test_cmp expect actual
'
ref-filter: apply --ignore-case to all sorting keys 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-05-03 09:11:57 +00:00
test_expect_success 'for-each-ref --ignore-case works on multiple sort keys' '
# name refs numerically to avoid case-insensitive filesystem conflicts
nr=0 &&
for email in a A b B
do
for subject in a A b B
do
GIT_COMMITTER_EMAIL="$email@example.com" \
git tag -m "tag $subject" icase-$(printf %02d $nr) &&
nr=$((nr+1))||
return 1
done
done &&
git for-each-ref --ignore-case \
--format="%(taggeremail) %(subject) %(refname)" \
--sort=refname \
--sort=subject \
--sort=taggeremail \
refs/tags/icase-* >actual &&
cat >expect <<-\EOF &&
<a@example.com> tag a refs/tags/icase-00
<a@example.com> tag A refs/tags/icase-01
<A@example.com> tag a refs/tags/icase-04
<A@example.com> tag A refs/tags/icase-05
<a@example.com> tag b refs/tags/icase-02
<a@example.com> tag B refs/tags/icase-03
<A@example.com> tag b refs/tags/icase-06
<A@example.com> tag B refs/tags/icase-07
<b@example.com> tag a refs/tags/icase-08
<b@example.com> tag A refs/tags/icase-09
<B@example.com> tag a refs/tags/icase-12
<B@example.com> tag A refs/tags/icase-13
<b@example.com> tag b refs/tags/icase-10
<b@example.com> tag B refs/tags/icase-11
<B@example.com> tag b refs/tags/icase-14
<B@example.com> tag B refs/tags/icase-15
EOF
test_cmp expect actual
'
Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 11:02:57 +00:00
test_done
Reference in a new issue Copy permalink