2006-12-20 02:25:32 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
2007-07-03 05:52:14 +00:00
|
|
|
test_description='git rev-list --max-count and --skip test'
|
2006-12-20 02:25:32 +00:00
|
|
|
|
revisions API: have release_revisions() release "cmdline"
Extend the the release_revisions() function so that it frees the
"cmdline" in the "struct rev_info". This in combination with a
preceding change to free "commits" and "mailmap" means that we can
whitelist another test under "TEST_PASSES_SANITIZE_LEAK=true".
There was a proposal in [1] to do away with xstrdup()-ing this
add_rev_cmdline(), perhaps that would be worthwhile, but for now let's
just free() it.
We could also make that a "char *" in "struct rev_cmdline_entry"
itself, but since we own it let's expose it as a constant to outside
callers. I proposed that in [2] but have since changed my mind. See
14d30cdfc04 (ref-filter: fix memory leak in `free_array_item()`,
2019-07-10), c514c62a4fd (checkout: fix leak of non-existent branch
names, 2020-08-14) and other log history hits for "free((char *)" for
prior art.
This includes the tests we had false-positive passes on before my
6798b08e848 (perl Git.pm: don't ignore signalled failure in
_cmd_close(), 2022-02-01), now they pass for real.
Since there are 66 tests matching t/t[0-9]*git-svn*.sh it's easier to
list those that don't pass than to touch most of those 66. So let's
introduce a "TEST_FAILS_SANITIZE_LEAK=true", which if set in the tests
won't cause lib-git-svn.sh to set "TEST_PASSES_SANITIZE_LEAK=true.
This change also marks all the tests that we removed
"TEST_FAILS_SANITIZE_LEAK=true" from in an earlier commit due to
removing the UNLEAK() from cmd_format_patch(), we can now assert that
its API use doesn't leak any "struct rev_info" memory.
This change also made commit "t5503-tagfollow.sh" pass on current
master, but that would regress when combined with
ps/fetch-atomic-fixup's de004e848a9 (t5503: simplify setup of test
which exercises failure of backfill, 2022-03-03) (through no fault of
that topic, that change started using "git clone" in the test, which
has an outstanding leak). Let's leave that test out for now to avoid
in-flight semantic conflicts.
1. https://lore.kernel.org/git/YUj%2FgFRh6pwrZalY@carlos-mbp.lan/
2. https://lore.kernel.org/git/87o88obkb1.fsf@evledraar.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 20:01:47 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2006-12-20 02:25:32 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
tests: fix broken &&-chains in compound statements
The top-level &&-chain checker built into t/test-lib.sh causes tests to
magically exit with code 117 if the &&-chain is broken. However, it has
the shortcoming that the magic does not work within `{...}` groups,
`(...)` subshells, `$(...)` substitutions, or within bodies of compound
statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed`
partly fills in the gap by catching broken &&-chains in `(...)`
subshells, but bugs can still lurk behind broken &&-chains in the other
cases.
Fix broken &&-chains in compound statements in order to reduce the
number of possible lurking bugs.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-09 05:11:06 +00:00
|
|
|
for n in 1 2 3 4 5 ; do
|
|
|
|
echo $n > a &&
|
|
|
|
git add a &&
|
2021-12-09 05:11:15 +00:00
|
|
|
git commit -m "$n" || return 1
|
2006-12-20 02:25:32 +00:00
|
|
|
done
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no options' '
|
2022-03-07 12:48:53 +00:00
|
|
|
test_stdout_line_count = 5 git rev-list HEAD
|
2006-12-20 02:25:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--max-count' '
|
revision: parse integer arguments to --max-count, --skip, etc., more carefully
The "rev-list" and other commands in the "log" family, being the
oldest part of the system, use their own custom argument parsers,
and integer values of some options are parsed with atoi(), which
allows a non-digit after the number (e.g., "1q") to be silently
ignored. As a natural consequence, an argument that does not begin
with a digit (e.g., "q") silently becomes zero, too.
Switch to use strtol_i() and parse_timestamp() appropriately to
catch bogus input.
Note that one may naïvely expect that --max-count, --skip, etc., to
only take non-negative values, but we must allow them to also take
negative values, as an escape hatch to countermand a limit set by an
earlier option on the command line; the underlying variables are
initialized to (-1) and "--max-count=-1", for example, is a
legitimate way to reinitialize the limit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-08 22:35:23 +00:00
|
|
|
test_must_fail git rev-list --max-count=1q HEAD 2>error &&
|
|
|
|
grep "not an integer" error &&
|
|
|
|
|
2022-03-07 12:48:53 +00:00
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --max-count=0 &&
|
|
|
|
test_stdout_line_count = 3 git rev-list HEAD --max-count=3 &&
|
|
|
|
test_stdout_line_count = 5 git rev-list HEAD --max-count=5 &&
|
revision: parse integer arguments to --max-count, --skip, etc., more carefully
The "rev-list" and other commands in the "log" family, being the
oldest part of the system, use their own custom argument parsers,
and integer values of some options are parsed with atoi(), which
allows a non-digit after the number (e.g., "1q") to be silently
ignored. As a natural consequence, an argument that does not begin
with a digit (e.g., "q") silently becomes zero, too.
Switch to use strtol_i() and parse_timestamp() appropriately to
catch bogus input.
Note that one may naïvely expect that --max-count, --skip, etc., to
only take non-negative values, but we must allow them to also take
negative values, as an escape hatch to countermand a limit set by an
earlier option on the command line; the underlying variables are
initialized to (-1) and "--max-count=-1", for example, is a
legitimate way to reinitialize the limit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-08 22:35:23 +00:00
|
|
|
test_stdout_line_count = 5 git rev-list HEAD --max-count=10 &&
|
|
|
|
test_stdout_line_count = 5 git rev-list HEAD --max-count=-1
|
2006-12-20 02:25:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--max-count all forms' '
|
revision: parse integer arguments to --max-count, --skip, etc., more carefully
The "rev-list" and other commands in the "log" family, being the
oldest part of the system, use their own custom argument parsers,
and integer values of some options are parsed with atoi(), which
allows a non-digit after the number (e.g., "1q") to be silently
ignored. As a natural consequence, an argument that does not begin
with a digit (e.g., "q") silently becomes zero, too.
Switch to use strtol_i() and parse_timestamp() appropriately to
catch bogus input.
Note that one may naïvely expect that --max-count, --skip, etc., to
only take non-negative values, but we must allow them to also take
negative values, as an escape hatch to countermand a limit set by an
earlier option on the command line; the underlying variables are
initialized to (-1) and "--max-count=-1", for example, is a
legitimate way to reinitialize the limit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-08 22:35:23 +00:00
|
|
|
test_must_fail git rev-list -1q HEAD 2>error &&
|
|
|
|
grep "not an integer" error &&
|
|
|
|
test_must_fail git rev-list --1 HEAD &&
|
|
|
|
test_must_fail git rev-list -n 1q HEAD 2>error &&
|
|
|
|
grep "not an integer" error &&
|
|
|
|
|
2022-03-07 12:48:53 +00:00
|
|
|
test_stdout_line_count = 1 git rev-list HEAD --max-count=1 &&
|
|
|
|
test_stdout_line_count = 1 git rev-list HEAD -1 &&
|
|
|
|
test_stdout_line_count = 1 git rev-list HEAD -n1 &&
|
revision: parse integer arguments to --max-count, --skip, etc., more carefully
The "rev-list" and other commands in the "log" family, being the
oldest part of the system, use their own custom argument parsers,
and integer values of some options are parsed with atoi(), which
allows a non-digit after the number (e.g., "1q") to be silently
ignored. As a natural consequence, an argument that does not begin
with a digit (e.g., "q") silently becomes zero, too.
Switch to use strtol_i() and parse_timestamp() appropriately to
catch bogus input.
Note that one may naïvely expect that --max-count, --skip, etc., to
only take non-negative values, but we must allow them to also take
negative values, as an escape hatch to countermand a limit set by an
earlier option on the command line; the underlying variables are
initialized to (-1) and "--max-count=-1", for example, is a
legitimate way to reinitialize the limit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-08 22:35:23 +00:00
|
|
|
test_stdout_line_count = 1 git rev-list HEAD -n 1 &&
|
|
|
|
test_stdout_line_count = 5 git rev-list HEAD -n -1
|
2006-12-20 02:25:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--skip' '
|
revision: parse integer arguments to --max-count, --skip, etc., more carefully
The "rev-list" and other commands in the "log" family, being the
oldest part of the system, use their own custom argument parsers,
and integer values of some options are parsed with atoi(), which
allows a non-digit after the number (e.g., "1q") to be silently
ignored. As a natural consequence, an argument that does not begin
with a digit (e.g., "q") silently becomes zero, too.
Switch to use strtol_i() and parse_timestamp() appropriately to
catch bogus input.
Note that one may naïvely expect that --max-count, --skip, etc., to
only take non-negative values, but we must allow them to also take
negative values, as an escape hatch to countermand a limit set by an
earlier option on the command line; the underlying variables are
initialized to (-1) and "--max-count=-1", for example, is a
legitimate way to reinitialize the limit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-08 22:35:23 +00:00
|
|
|
test_must_fail git rev-list --skip 1q HEAD 2>error &&
|
|
|
|
grep "not an integer" error &&
|
|
|
|
|
2022-03-07 12:48:53 +00:00
|
|
|
test_stdout_line_count = 5 git rev-list HEAD --skip=0 &&
|
|
|
|
test_stdout_line_count = 2 git rev-list HEAD --skip=3 &&
|
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --skip=5 &&
|
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --skip=10
|
2006-12-20 02:25:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--skip --max-count' '
|
2022-03-07 12:48:53 +00:00
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --skip=0 --max-count=0 &&
|
|
|
|
test_stdout_line_count = 5 git rev-list HEAD --skip=0 --max-count=10 &&
|
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --skip=3 --max-count=0 &&
|
|
|
|
test_stdout_line_count = 1 git rev-list HEAD --skip=3 --max-count=1 &&
|
|
|
|
test_stdout_line_count = 2 git rev-list HEAD --skip=3 --max-count=2 &&
|
|
|
|
test_stdout_line_count = 2 git rev-list HEAD --skip=3 --max-count=10 &&
|
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --skip=5 --max-count=10 &&
|
|
|
|
test_stdout_line_count = 0 git rev-list HEAD --skip=10 --max-count=10
|
2006-12-20 02:25:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|