summaryrefslogtreecommitdiff
path: root/t/diff-lib/README
diff options
context:
space:
mode:
authorLibravatar Elijah Newren <newren@gmail.com>2020-12-01 22:25:16 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-12-01 14:39:04 -0800
commita31e48d39429415d2afa35f2c8421482e06a0677 (patch)
treee6eda272b1e69bf168b34b4a33e6bde3ddff5e35 /t/diff-lib/README
parentSixth batch (diff)
downloadtgif-a31e48d39429415d2afa35f2c8421482e06a0677.tar.xz
t7012: add a testcase demonstrating stash apply bugs in sparse checkouts
Applying stashes in sparse-checkouts, particularly when the patterns used to define the sparseness have changed between when the stash was created and when it is applied, has a number of bugs. The primary problem is that stashes are sometimes only partially applied. In most such cases, it does so silently without any warning or error being displayed and with 0 exit status. There are, however, a few cases when non-translated error messages are shown and the stash application aborts early. The first is when there are files present despite the SKIP_WORKTREE bit being set, in which case the error message shown is: error: Entry 'PATHNAME' not uptodate. Cannot merge. The other situation is when a stash contains new files to add to the working tree; in this case, the code aborts early but still has the stash partially applied, and shows the following error message: error: NEWFILE: does not exist and --remove not passed fatal: Unable to process path NEWFILE Add a test that can trigger all three of these problems. Have it carefully check that the working copy and SKIP_WORKTREE bits are as expected after the stash application. The test is currently marked as expected to fail, but subsequent commits will implement the fixes and toggle the expectation. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/diff-lib/README')
0 files changed, 0 insertions, 0 deletions