2019-04-25 09:45:55 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='git restore --patch'
|
|
|
|
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2019-04-25 09:45:55 +00:00
|
|
|
. ./lib-patch-mode.sh
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'setup' '
|
2019-04-25 09:45:55 +00:00
|
|
|
mkdir dir &&
|
|
|
|
echo parent >dir/foo &&
|
|
|
|
echo dummy >bar &&
|
|
|
|
git add bar dir/foo &&
|
|
|
|
git commit -m initial &&
|
|
|
|
test_tick &&
|
|
|
|
test_commit second dir/foo head &&
|
|
|
|
set_and_save_state bar bar_work bar_index &&
|
|
|
|
save_head
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'restore -p without pathspec is fine' '
|
2019-04-25 09:45:55 +00:00
|
|
|
echo q >cmd &&
|
|
|
|
git restore -p <cmd
|
|
|
|
'
|
|
|
|
|
|
|
|
# note: bar sorts before dir/foo, so the first 'n' is always to skip 'bar'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'saying "n" does nothing' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_and_save_state dir/foo work head &&
|
|
|
|
test_write_lines n n | git restore -p &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_saved_state dir/foo
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'git restore -p' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_and_save_state dir/foo work head &&
|
|
|
|
test_write_lines n y | git restore -p &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo head head
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'git restore -p with staged changes' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work index &&
|
|
|
|
test_write_lines n y | git restore -p &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo index index
|
|
|
|
'
|
|
|
|
|
add-patch: classify '@' as a synonym for 'HEAD'
Currently, (restore, checkout, reset) commands correctly take '@' as a
synonym for 'HEAD'. However, in patch mode different prompts/messages
are given on command line due to patch mode machinery not considering
'@' to be a synonym for 'HEAD' due to literal string comparison with
the word 'HEAD', and therefore assigning patch_mode_($command)_nothead
and triggering reverse mode (-R in diff-index). The NEEDSWORK comment
suggested comparing commit objects to get around this. However, doing
so would also take a non-checked out branch pointing to the same commit
as HEAD, as HEAD. This would cause confusion to the user.
Therefore, after parsing '@', replace it with 'HEAD' as reasonably
early as possible. This also solves another problem of disparity
between 'git checkout HEAD' and 'git checkout @' (latter detaches at
the HEAD commit and the former does not).
Trade-offs:
- Some of the errors would show the revision argument as 'HEAD' when
given '@'. This should be fine, as most users who probably use '@'
would be aware that it is a shortcut for 'HEAD' and most probably
used to use 'HEAD'. There is also relevant documentation in
'gitrevisions' manpage about '@' being the shortcut for 'HEAD'. Also,
the simplicity of the solution far outweighs this cost.
- Consider '@' as a shortcut for 'HEAD' even if 'refs/heads/@' exists
at a different commit. Naming a branch '@' is an obvious foot-gun and
many existing commands already take '@' for 'HEAD' even if
'refs/heads/@' exists at a different commit or does not exist at all
(e.g. 'git log @', 'git push origin @' etc.). Therefore this is an
existing assumption and should not be a problem.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-13 00:05:29 +00:00
|
|
|
for opt in "HEAD" "@"
|
|
|
|
do
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success "git restore -p --source=$opt" '
|
add-patch: classify '@' as a synonym for 'HEAD'
Currently, (restore, checkout, reset) commands correctly take '@' as a
synonym for 'HEAD'. However, in patch mode different prompts/messages
are given on command line due to patch mode machinery not considering
'@' to be a synonym for 'HEAD' due to literal string comparison with
the word 'HEAD', and therefore assigning patch_mode_($command)_nothead
and triggering reverse mode (-R in diff-index). The NEEDSWORK comment
suggested comparing commit objects to get around this. However, doing
so would also take a non-checked out branch pointing to the same commit
as HEAD, as HEAD. This would cause confusion to the user.
Therefore, after parsing '@', replace it with 'HEAD' as reasonably
early as possible. This also solves another problem of disparity
between 'git checkout HEAD' and 'git checkout @' (latter detaches at
the HEAD commit and the former does not).
Trade-offs:
- Some of the errors would show the revision argument as 'HEAD' when
given '@'. This should be fine, as most users who probably use '@'
would be aware that it is a shortcut for 'HEAD' and most probably
used to use 'HEAD'. There is also relevant documentation in
'gitrevisions' manpage about '@' being the shortcut for 'HEAD'. Also,
the simplicity of the solution far outweighs this cost.
- Consider '@' as a shortcut for 'HEAD' even if 'refs/heads/@' exists
at a different commit. Naming a branch '@' is an obvious foot-gun and
many existing commands already take '@' for 'HEAD' even if
'refs/heads/@' exists at a different commit or does not exist at all
(e.g. 'git log @', 'git push origin @' etc.). Therefore this is an
existing assumption and should not be a problem.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-13 00:05:29 +00:00
|
|
|
set_state dir/foo work index &&
|
|
|
|
# the third n is to get out in case it mistakenly does not apply
|
|
|
|
test_write_lines n y n | git restore -p --source=$opt >output &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo head index &&
|
|
|
|
test_grep "Discard" output
|
|
|
|
'
|
|
|
|
done
|
2019-04-25 09:45:55 +00:00
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'git restore -p --source=HEAD^' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work index &&
|
|
|
|
# the third n is to get out in case it mistakenly does not apply
|
|
|
|
test_write_lines n y n | git restore -p --source=HEAD^ &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo parent index
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'git restore -p --source=HEAD^...' '
|
2020-10-07 07:56:15 +00:00
|
|
|
set_state dir/foo work index &&
|
|
|
|
# the third n is to get out in case it mistakenly does not apply
|
|
|
|
test_write_lines n y n | git restore -p --source=HEAD^... &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo parent index
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'git restore -p handles deletion' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work index &&
|
|
|
|
rm dir/foo &&
|
|
|
|
test_write_lines n y | git restore -p &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo index index
|
|
|
|
'
|
|
|
|
|
|
|
|
# The idea in the rest is that bar sorts first, so we always say 'y'
|
|
|
|
# first and if the path limiter fails it'll apply to bar instead of
|
|
|
|
# dir/foo. There's always an extra 'n' to reject edits to dir/foo in
|
|
|
|
# the failure case (and thus get out of the loop).
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'path limiting works: dir' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work head &&
|
|
|
|
test_write_lines y n | git restore -p dir &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo head head
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'path limiting works: -- dir' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work head &&
|
|
|
|
test_write_lines y n | git restore -p -- dir &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo head head
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'path limiting works: HEAD^ -- dir' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work head &&
|
|
|
|
# the third n is to get out in case it mistakenly does not apply
|
|
|
|
test_write_lines y n n | git restore -p --source=HEAD^ -- dir &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo parent head
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'path limiting works: foo inside dir' '
|
2019-04-25 09:45:55 +00:00
|
|
|
set_state dir/foo work head &&
|
|
|
|
# the third n is to get out in case it mistakenly does not apply
|
|
|
|
test_write_lines y n n | (cd dir && git restore -p foo) &&
|
|
|
|
verify_saved_state bar &&
|
|
|
|
verify_state dir/foo head head
|
|
|
|
'
|
|
|
|
|
2024-02-13 00:05:30 +00:00
|
|
|
test_expect_success 'none of this moved HEAD' '
|
2019-04-25 09:45:55 +00:00
|
|
|
verify_saved_head
|
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|