t1011: add testcase demonstrating accidental loss of user modifications
If a user has a file with local modifications that is not marked as SKIP_WORKTREE, but the sparsity patterns are such that it should be marked that way, and the user then invokes a command like * git checkout -q HEAD^ or * git read-tree -mu HEAD^ Then the file will be deleted along with all the users' modifications. Add a testcase demonstrating this problem. Note: This bug only triggers if something other than 'HEAD' is given; if the commands above had specified 'HEAD', then the users' file would be left alone. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren committed
Jan 14, 2022 at 15:59 UTC
b3df8c982a1bfb21b7803ca01d72951966505fb2
1 file changed
+21
t/t1011-read-tree-sparse-checkout.sh
+21
@@ -187,6 +187,27 @@ test_expect_success 'read-tree updates worktree, absent case' '
187
test ! -f init.t
188
'
189
190
+test_expect_success 'read-tree will not throw away dirty changes, non-sparse' '
191
+ echo "/*" >.git/info/sparse-checkout &&
192
+ read_tree_u_must_succeed -m -u HEAD &&
193
+
194
+ echo dirty >init.t &&
195
+ read_tree_u_must_fail -m -u HEAD^ &&
196
+ test_path_is_file init.t &&
197
+ grep -q dirty init.t
198
+'
199
+
200
+test_expect_failure 'read-tree will not throw away dirty changes, sparse' '
201
+ echo "/*" >.git/info/sparse-checkout &&
202
+ read_tree_u_must_succeed -m -u HEAD &&
203
+
204
+ echo dirty >init.t &&
205
+ echo sub/added >.git/info/sparse-checkout &&
206
+ read_tree_u_must_fail -m -u HEAD^ &&
207
+ test_path_is_file init.t &&
208
+ grep -q dirty init.t
209
+'
210
+
211
test_expect_success 'read-tree updates worktree, dirty case' '
212
echo sub/added >.git/info/sparse-checkout &&
213
git checkout -f top &&