path: root/t/
AgeCommit message (Collapse)Author
2020-04-08stash -p: (partially) fix bug concerning split hunksJohannes Schindelin
When trying to stash part of the worktree changes by splitting a hunk and then only partially accepting the split bits and pieces, the user is presented with a rather cryptic error: error: patch failed: <file>:<line> error: test: patch does not apply Cannot remove worktree changes and the command would fail to stash the desired parts of the worktree changes (even if the `stash` ref was actually updated correctly). We even have a test case demonstrating that failure, carrying it for four years already. The explanation: when splitting a hunk, the changed lines are no longer separated by more than 3 lines (which is the amount of context lines Git's diffs use by default), but less than that. So when staging only part of the diff hunk for stashing, the resulting diff that we want to apply to the worktree in reverse will contain those changes to be dropped surrounded by three context lines, but since the diff is relative to HEAD rather than to the worktree, these context lines will not match. Example time. Let's assume that the file README contains these lines: We the people and the worktree added some lines so that it contains these lines instead: We are the kind people and the user tries to stash the line containing "are", then the command will internally stage this line to a temporary index file and try to revert the diff between HEAD and that index file. The diff hunk that `git stash` tries to revert will look somewhat like this: @@ -1776,3 +1776,4 We +are the people It is obvious, now, that the trailing context lines overlap with the part of the original diff hunk that the user did *not* want to stash. Keeping in mind that context lines in diffs serve the primary purpose of finding the exact location when the diff does not apply precisely (but when the exact line number in the file to be patched differs from the line number indicated in the diff), we work around this by reducing the amount of context lines: the diff was just generated. Note: this is not a *full* fix for the issue. Just as demonstrated in t3701's 'add -p works with pathological context lines' test case, there are ambiguities in the diff format. It is very rare in practice, of course, to encounter such repeated lines. The full solution for such cases would be to replace the approach of generating a diff from the stash and then applying it in reverse by emulating `git revert` (i.e. doing a 3-way merge). However, in `git stash -p` it would not apply to `HEAD` but instead to the worktree, which makes this non-trivial to implement as long as we also maintain a scripted version of `add -i`. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-04-08t3904: fix incorrect demonstration of a bugJohannes Schindelin
In 7e9e048661 (stash -p: demonstrate failure of split with mixed y/n, 2015-04-16), a regression test for a known breakage that was added to the test script `` that demonstrated that splitting a hunk and trying to stash only part of that split hunk fails (but shouldn't). As expected, it still fails, but for the wrong reason: once the bug is fixed, we would expect stderr to show nothing, yet the regression test expects stderr to show something. Let's fix that by telling that regression test case to expect nothing to be printed to stderr. While at it, also drop the obvious left-over from debugging where the regression test did not mind `git stash -p` to return a non-zero exit status. Of course, the regression test still fails, but this time for the correct reason. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2017-03-22stash: pass the pathspec argument to git resetThomas Gummerer
For "git stash -p --no-keep-index", the pathspec argument is currently not passed to "git reset". This means that changes that are staged but that are excluded from the pathspec still get unstaged by git stash -p. Make sure that doesn't happen by passing the pathspec argument to the git reset in question, bringing the behaviour in line with "git stash -- <pathspec>". Signed-off-by: Thomas Gummerer <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-04-16stash -p: demonstrate failure of split with mixed y/nMatthieu Moy
Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2015-04-16t3904-stash-patch: factor PERL prereq at the top of the fileMatthieu Moy
Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2015-04-16t3904-stash-patch: fix test descriptionMatthieu Moy
The old description is rather clearly a wrong cut-and-paste from Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2012-01-01stash: Don't fail if work dir contains file named 'HEAD'Jonathon Mah
When performing a plain "git stash" (without --patch), git-diff would fail with "fatal: ambiguous argument 'HEAD': both revision and filename". The output was piped into git-update-index, masking the failed exit status. The output is now sent to a temporary file (which is cleaned up by existing code), and the exit status is checked. The "HEAD" arg to the git-diff invocation has been disambiguated too, of course. In patch mode, "git stash -p" would fail harmlessly, leaving the working dir untouched. Interactive adding is fine, but the resulting tree was diffed with an ambiguous 'HEAD' argument. Use >foo (no space) when redirecting output. In t3904, checks and operations on each file are in the order they'll appear when interactively staging. In t3905, fix a bug in "stash save --include-untracked -q is quiet": The redirected stdout file was considered untracked, and so was removed from the working directory. Use test path helper functions where appropriate. Signed-off-by: Jonathon Mah <> Acked-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2011-04-07stash: ensure --no-keep-index and --patch can be used in any orderDan McGee
Don't assume one comes after the other on the command line. Use a three-state variable to track and check its value accordingly. Signed-off-by: Dan McGee <> Signed-off-by: Junio C Hamano <>
2011-04-07stash: add two more tests for --no-keep-indexDan McGee
One of these passes just fine; the other one exposes a problem where command line flag order matters for --no-keep-index and --patch interaction. Signed-off-by: Dan McGee <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2009-08-15Implement 'git stash save --patch'Thomas Rast
This adds a hunk-based mode to git-stash. You can select hunks from the difference between HEAD and worktree, and git-stash will build a stash that reflects these changes. The index state of the stash is the same as your current index, and we also let --patch imply --keep-index. Note that because the selected hunks are rolled back from the worktree but not the index, the resulting state may appear somewhat confusing if you had also staged these changes. This is not entirely satisfactory, but due to the way stashes are applied, other solutions would require a change to the stash format. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>