summaryrefslogtreecommitdiff
path: root/t/t2016-checkout-patch.sh
AgeCommit message (Collapse)Author
2022-06-15add -i tests: mark "TODO" depending on GIT_TEST_ADD_I_USE_BUILTINÆvar Arnfjörð Bjarmason
Fix an issue that existed before 0527ccb1b55 (add -i: default to the built-in implementation, 2021-11-30), but which became the default with that change, we should not be marking tests that are known to pass as "TODO" tests. When GIT_TEST_ADD_I_USE_BUILTIN=1 was made the default we started passing the tests added in 0f0fba2cc87 (t3701: add a test for advanced split-hunk editing, 2019-12-06) and 1bf01040f0c (add -p: demonstrate failure when running 'edit' after a split, 2015-04-16). Thus we've been emitting this sort of output: $ prove ./t3701-add-interactive.sh ./t3701-add-interactive.sh .. ok All tests successful. Test Summary Report ------------------- ./t3701-add-interactive.sh (Wstat: 0 Tests: 70 Failed: 0) TODO passed: 45, 47 Files=1, Tests=70, 2 wallclock secs ( 0.03 usr 0.00 sys + 0.86 cusr 0.33 csys = 1.22 CPU) Result: PASS Which isn't just cosmetic, but due to issues with test_expect_failure (see [1]) we could e.g. be hiding something as bad as a segfault in the new implementation. It makes sense catch that, especially before we put out a release with the built-in "add -i", so let's generalize the check we were already doing in 0527ccb1b55 with a new "ADD_I_USE_BUILTIN" prerequisite. 1. https://lore.kernel.org/git/patch-1.7-4624abc2591-20220318T002951Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01add -i: default to the built-in implementationJohannes Schindelin
In 9a5315edfdf (Merge branch 'js/patch-mode-in-others-in-c', 2020-02-05), Git acquired a built-in implementation of `git add`'s interactive mode that could be turned on via the config option `add.interactive.useBuiltin`. The first official Git version to support this knob was v2.26.0. In 2df2d81ddd0 (add -i: use the built-in version when feature.experimental is set, 2020-09-08), this built-in implementation was also enabled via `feature.experimental`. The first version with this change was v2.29.0. More than a year (and very few bug reports) later, it is time to declare the built-in implementation mature and to turn it on by default. We specifically leave the `add.interactive.useBuiltin` configuration in place, to give users an "escape hatch" in the unexpected case should they encounter a previously undetected bug in that implementation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01t2016: require the PERL prereq only when necessaryJohannes Schindelin
The scripted version of the interactive mode of `git add` still requires Perl, but the built-in version does not. Let's only require the PERL prereq if testing the scripted version. This addresses a long-standing NEEDSWORK added in 35166b1fb54 (t2016: add a NEEDSWORK about the PERL prerequisite, 2020-10-07). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21checkout -p: handle tree arguments correctly againJohannes Schindelin
This fixes a segmentation fault. The bug is caused by dereferencing `new_branch_info->commit` when it is `NULL`, which is the case when the tree-ish argument is actually a tree, not a commit-ish. This was introduced in 5602b500c3c (builtin/checkout: fix `git checkout -p HEAD...` bug, 2020-10-07), where we tried to ensure that the special tree-ish `HEAD...` is handled correctly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07t2016: add a NEEDSWORK about the PERL prerequisiteDenton Liu
Since the builtin add-p is used when $GIT_TEST_ADD_I_USE_BUILTIN is given, we should replace the PERL prerequisite with an ADD_I prerequisite which first checks if $GIT_TEST_ADD_I_USE_BUILTIN is defined before checking PERL.[0] Mark this in a NEEDSWORK so that it can be addressed at a later time. [0]: https://lore.kernel.org/git/xmqqsgat7ttf.fsf@gitster.c.googlers.com/ Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07builtin/checkout: fix `git checkout -p HEAD...` bugDenton Liu
Running `git checkout -p` with a merge-base rev results in an error: $ git checkout -p HEAD... usage: git diff-index [-m] [--cached] [<common-diff-options>] <tree-ish> [<path>...] common diff options: -z output diff-raw with lines terminated with NUL. -p output patch format. -u synonym for -p. --patch-with-raw output both a patch and the diff-raw format. --stat show diffstat instead of patch. --numstat show numeric diffstat instead of patch. --patch-with-stat output a patch and prepend its diffstat. --name-only show only names of changed files. --name-status show names and status of changed files. --full-index show full object name on index lines. --abbrev=<n> abbreviate object names in diff-tree header and diff-raw. -R swap input file pairs. -B detect complete rewrites. -M detect renames. -C detect copies. --find-copies-harder try unchanged files as candidate for copy detection. -l<n> limit rename attempts up to <n> paths. -O<file> reorder diffs according to the <file>. -S<string> find filepair whose only one side contains the string. --pickaxe-all show all files diff when -S is used and hit is found. -a --text treat all files as text. Cannot close git diff-index --cached --numstat --summary HEAD... -- () at <redacted>/libexec/git-core/git-add--interactive line 183. This happens because checkout passes the literal argument (in the example, `HEAD...`) to diff-index which does not recognise merge-base revs. Fix this by using the hex of the found commit instead of the given name. Note that "HEAD" is handled specially in run_add_interactive() so it's explicitly not changed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t: use test_write_lines() instead of series of 'echo' commandsEric Sunshine
These tests employ a noisy subshell (with missing &&-chain) to feed input into Git commands or files: (echo a; echo b; echo c) | git some-command ... Simplify by taking advantage of test_write_lines(): test_write_lines a b c | git some-command ... Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Jonathan Nieder
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-09t2016 (checkout -p): add missing &&Jonathan Nieder
Although the set_state command is not likely to fail, it is best to stay in the habit of checking for failures. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18lib-patch-mode tests: change from skip_all=* to prereq skipÆvar Arnfjörð Bjarmason
Change this test to skip test with test prerequisites, and to do setup work in tests. This improves the skipped statistics on platforms where the test isn't run. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23add-interactive: fix bogus diff header line orderingJeff King
When we look at a patch for adding hunks interactively, we first split it into a header and a list of hunks. Some of the header lines, such as mode changes and deletion, however, become their own selectable hunks. Later when we reassemble the patch, we simply concatenate the header and the selected hunks. This leads to patches like this: diff --git a/file b/file index d95f3ad..0000000 --- a/file +++ /dev/null deleted file mode 100644 @@ -1 +0,0 @@ -content Notice how the deletion comes _after_ the ---/+++ lines, when it should come before. In many cases, we can get away with this as git-apply accepts the slightly bogus input. However, in the specific case of a deletion line that is being applied via "apply -R", this malformed patch triggers an assert in git-apply. This comes up when discarding a deletion via "git checkout -p". Rather than try to make git-apply accept our odd input, let's just reassemble the patch in the correct order. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-27Make test case number uniqueJohannes Sixt
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>