git/t/t7102-reset.sh

639 lines
16 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2007 Carlos Rica
#
test_description='git reset
Documented tests for git reset'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:19 +08:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
if test_have_prereq ICONV
then
commit_msg () {
# String "modify 2nd file (changed)" partly in German
# (translated with Google Translate),
# encoded in UTF-8, used as a commit log message below.
msg="modify 2nd file (ge\303\244ndert)\n"
if test -n "$1"
then
printf "$msg" | iconv -f utf-8 -t "$1"
else
printf "$msg"
fi
}
# Tested non-UTF-8 encoding
test_encoding="ISO8859-1"
else
commit_msg () {
echo "modify 2nd file (geandert)"
}
# Tested non-UTF-8 encoding
test_encoding="UTF-8"
fi
test_expect_success 'creating initial files and commits' '
test_tick &&
echo "1st file" >first &&
git add first &&
git commit -m "create 1st file" &&
echo "2nd file" >second &&
git add second &&
git commit -m "create 2nd file" &&
echo "2nd line 1st file" >>first &&
git commit -a -m "modify 1st file" &&
head5p2=$(git rev-parse --verify HEAD) &&
head5p2f=$(git rev-parse --short HEAD:first) &&
git rm first &&
git mv second secondfile &&
git commit -a -m "remove 1st and rename 2nd" &&
head5p1=$(git rev-parse --verify HEAD) &&
head5p1s=$(git rev-parse --short HEAD:secondfile) &&
echo "1st line 2nd file" >secondfile &&
echo "2nd line 2nd file" >>secondfile &&
# "git commit -m" would break MinGW, as Windows refuse to pass
# $test_encoding encoded parameter to git.
commit_msg $test_encoding | git -c "i18n.commitEncoding=$test_encoding" commit -a -F - &&
head5=$(git rev-parse --verify HEAD) &&
head5s=$(git rev-parse --short HEAD:secondfile) &&
head5sl=$(git rev-parse HEAD:secondfile)
'
# git log --pretty=oneline # to see those SHA1 involved
check_changes () {
test "$(git rev-parse HEAD)" = "$1" &&
git diff | test_cmp .diff_expect - &&
git diff --cached | test_cmp .cached_expect - &&
for FILE in *
do
echo $FILE':'
cat $FILE || return
done | test_cmp .cat_expect -
}
# no negated form for various type of resets
for opt in soft mixed hard merge keep
do
test_expect_success "no 'git reset --no-$opt'" '
test_when_finished "rm -f err" &&
test_must_fail git reset --no-$opt 2>err &&
grep "error: unknown option .no-$opt." err
'
done
test_expect_success 'reset --hard message' '
hex=$(git log -1 --format="%h") &&
git reset --hard >.actual &&
echo HEAD is now at $hex $(commit_msg) >.expected &&
test_cmp .expected .actual
'
test_expect_success 'reset --hard message (ISO8859-1 logoutputencoding)' '
hex=$(git log -1 --format="%h") &&
git -c "i18n.logOutputEncoding=$test_encoding" reset --hard >.actual &&
echo HEAD is now at $hex $(commit_msg $test_encoding) >.expected &&
test_cmp .expected .actual
'
test_expect_success 'giving a non existing revision should fail' '
>.diff_expect &&
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
EOF
test_must_fail git reset aaaaaa &&
test_must_fail git reset --mixed aaaaaa &&
test_must_fail git reset --soft aaaaaa &&
test_must_fail git reset --hard aaaaaa &&
check_changes $head5
'
test_expect_success 'reset --soft with unmerged index should fail' '
touch .git/MERGE_HEAD &&
echo "100644 $head5sl 1 un" |
git update-index --index-info &&
test_must_fail git reset --soft HEAD &&
rm .git/MERGE_HEAD &&
git rm --cached -- un
'
test_expect_success 'giving paths with options different than --mixed should fail' '
test_must_fail git reset --soft -- first &&
test_must_fail git reset --hard -- first &&
test_must_fail git reset --soft HEAD^ -- first &&
test_must_fail git reset --hard HEAD^ -- first &&
check_changes $head5
'
test_expect_success 'giving unrecognized options should fail' '
test_must_fail git reset --other &&
test_must_fail git reset -o &&
test_must_fail git reset --mixed --other &&
test_must_fail git reset --mixed -o &&
test_must_fail git reset --soft --other &&
test_must_fail git reset --soft -o &&
test_must_fail git reset --hard --other &&
test_must_fail git reset --hard -o &&
check_changes $head5
'
test_expect_success 'trying to do reset --soft with pending merge should fail' '
git branch branch1 &&
git branch branch2 &&
git checkout branch1 &&
echo "3rd line in branch1" >>secondfile &&
git commit -a -m "change in branch1" &&
git checkout branch2 &&
echo "3rd line in branch2" >>secondfile &&
git commit -a -m "change in branch2" &&
test_must_fail git merge branch1 &&
test_must_fail git reset --soft &&
printf "1st line 2nd file\n2nd line 2nd file\n3rd line" >secondfile &&
git commit -a -m "the change in branch2" &&
git checkout main &&
git branch -D branch1 branch2 &&
check_changes $head5
'
test_expect_success 'trying to do reset --soft with pending checkout merge should fail' '
git branch branch3 &&
git branch branch4 &&
git checkout branch3 &&
echo "3rd line in branch3" >>secondfile &&
git commit -a -m "line in branch3" &&
git checkout branch4 &&
echo "3rd line in branch4" >>secondfile &&
git checkout -m branch3 &&
test_must_fail git reset --soft &&
printf "1st line 2nd file\n2nd line 2nd file\n3rd line" >secondfile &&
git commit -a -m "the line in branch3" &&
git checkout main &&
git branch -D branch3 branch4 &&
check_changes $head5
'
test_expect_success 'resetting to HEAD with no changes should succeed and do nothing' '
git reset --hard &&
check_changes $head5 &&
git reset --hard HEAD &&
check_changes $head5 &&
git reset --soft &&
check_changes $head5 &&
git reset --soft HEAD &&
check_changes $head5 &&
git reset --mixed &&
check_changes $head5 &&
git reset --mixed HEAD &&
check_changes $head5 &&
git reset &&
check_changes $head5 &&
git reset HEAD &&
check_changes $head5
'
test_expect_success '--soft reset only should show changes in diff --cached' '
>.diff_expect &&
cat >.cached_expect <<-EOF &&
diff --git a/secondfile b/secondfile
index $head5p1s..$head5s 100644
--- a/secondfile
+++ b/secondfile
@@ -1 +1,2 @@
-2nd file
+1st line 2nd file
+2nd line 2nd file
EOF
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
EOF
git reset --soft HEAD^ &&
check_changes $head5p1 &&
test "$(git rev-parse ORIG_HEAD)" = \
$head5
'
test_expect_success 'changing files and redo the last commit should succeed' '
>.diff_expect &&
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
3rd line 2nd file
EOF
echo "3rd line 2nd file" >>secondfile &&
git commit -a -C ORIG_HEAD &&
head4=$(git rev-parse --verify HEAD) &&
check_changes $head4 &&
test "$(git rev-parse ORIG_HEAD)" = \
$head5
'
test_expect_success '--hard reset should change the files and undo commits permanently' '
>.diff_expect &&
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
first:
1st file
2nd line 1st file
second:
2nd file
EOF
git reset --hard HEAD~2 &&
check_changes $head5p2 &&
test "$(git rev-parse ORIG_HEAD)" = \
$head4
'
test_expect_success 'redoing changes adding them without commit them should succeed' '
>.diff_expect &&
cat >.cached_expect <<-EOF &&
diff --git a/first b/first
deleted file mode 100644
index $head5p2f..0000000
--- a/first
+++ /dev/null
@@ -1,2 +0,0 @@
-1st file
-2nd line 1st file
diff --git a/second b/second
deleted file mode 100644
index $head5p1s..0000000
--- a/second
+++ /dev/null
@@ -1 +0,0 @@
-2nd file
diff --git a/secondfile b/secondfile
new file mode 100644
index 0000000..$head5s
--- /dev/null
+++ b/secondfile
@@ -0,0 +1,2 @@
+1st line 2nd file
+2nd line 2nd file
EOF
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
EOF
git rm first &&
git mv second secondfile &&
echo "1st line 2nd file" >secondfile &&
echo "2nd line 2nd file" >>secondfile &&
git add secondfile &&
check_changes $head5p2
'
test_expect_success '--mixed reset to HEAD should unadd the files' '
cat >.diff_expect <<-EOF &&
diff --git a/first b/first
deleted file mode 100644
index $head5p2f..0000000
--- a/first
+++ /dev/null
@@ -1,2 +0,0 @@
-1st file
-2nd line 1st file
diff --git a/second b/second
deleted file mode 100644
index $head5p1s..0000000
--- a/second
+++ /dev/null
@@ -1 +0,0 @@
-2nd file
EOF
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
EOF
git reset &&
check_changes $head5p2 &&
test "$(git rev-parse ORIG_HEAD)" = $head5p2
'
test_expect_success 'redoing the last two commits should succeed' '
>.diff_expect &&
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
EOF
git add secondfile &&
git reset --hard $head5p2 &&
git rm first &&
git mv second secondfile &&
git commit -a -m "remove 1st and rename 2nd" &&
echo "1st line 2nd file" >secondfile &&
echo "2nd line 2nd file" >>secondfile &&
# "git commit -m" would break MinGW, as Windows refuse to pass
# $test_encoding encoded parameter to git.
commit_msg $test_encoding | git -c "i18n.commitEncoding=$test_encoding" commit -a -F - &&
check_changes $head5
'
test_expect_success '--hard reset to HEAD should clear a failed merge' '
>.diff_expect &&
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
3rd line in branch2
EOF
git branch branch1 &&
git branch branch2 &&
git checkout branch1 &&
echo "3rd line in branch1" >>secondfile &&
git commit -a -m "change in branch1" &&
git checkout branch2 &&
echo "3rd line in branch2" >>secondfile &&
git commit -a -m "change in branch2" &&
head3=$(git rev-parse --verify HEAD) &&
test_must_fail git pull . branch1 &&
git reset --hard &&
check_changes $head3
'
test_expect_success '--hard reset to ORIG_HEAD should clear a fast-forward merge' '
>.diff_expect &&
>.cached_expect &&
cat >.cat_expect <<-\EOF &&
secondfile:
1st line 2nd file
2nd line 2nd file
EOF
git reset --hard HEAD^ &&
check_changes $head5 &&
git pull . branch1 &&
git reset --hard ORIG_HEAD &&
check_changes $head5 &&
git checkout main &&
git branch -D branch1 branch2 &&
check_changes $head5
'
test_expect_success 'test --mixed <paths>' '
echo 1 >file1 &&
echo 2 >file2 &&
git add file1 file2 &&
test_tick &&
git commit -m files &&
before1=$(git rev-parse --short HEAD:file1) &&
before2=$(git rev-parse --short HEAD:file2) &&
git rm file2 &&
echo 3 >file3 &&
echo 4 >file4 &&
echo 5 >file1 &&
after1=$(git rev-parse --short $(git hash-object file1)) &&
after4=$(git rev-parse --short $(git hash-object file4)) &&
git add file1 file3 file4 &&
git reset HEAD -- file1 file2 file3 &&
test_must_fail git diff --quiet &&
git diff >output &&
cat >expect <<-EOF &&
diff --git a/file1 b/file1
index $before1..$after1 100644
--- a/file1
+++ b/file1
@@ -1 +1 @@
-1
+5
diff --git a/file2 b/file2
deleted file mode 100644
index $before2..0000000
--- a/file2
+++ /dev/null
@@ -1 +0,0 @@
-2
EOF
test_cmp expect output &&
git diff --cached >output &&
cat >cached_expect <<-EOF &&
diff --git a/file4 b/file4
new file mode 100644
index 0000000..$after4
--- /dev/null
+++ b/file4
@@ -0,0 +1 @@
+4
EOF
test_cmp cached_expect output
'
test_expect_success 'test resetting the index at give paths' '
mkdir sub &&
>sub/file1 &&
>sub/file2 &&
git update-index --add sub/file1 sub/file2 &&
T=$(git write-tree) &&
git reset HEAD sub/file2 &&
test_must_fail git diff --quiet &&
U=$(git write-tree) &&
echo "$T" &&
echo "$U" &&
test_must_fail git diff-index --cached --exit-code "$T" &&
test "$T" != "$U"
'
test_expect_success 'resetting an unmodified path is a no-op' '
git reset --hard &&
git reset -- file1 &&
git diff-files --exit-code &&
git diff-index --cached --exit-code HEAD
'
test_reset_refreshes_index () {
# To test whether the index is refreshed in `git reset --mixed` with
# the given options, create a scenario where we clearly see different
# results depending on whether the refresh occurred or not.
# Step 0: start with a clean index
git reset --hard HEAD &&
# Step 1: remove file2, but only in the index (no change to worktree)
git rm --cached file2 &&
# Step 2: reset index & leave worktree unchanged from HEAD
git $1 reset $2 --mixed HEAD &&
# Step 3: verify whether the index is refreshed by checking whether
# file2 still has staged changes in the index differing from HEAD (if
# the refresh occurred, there should be no such changes)
git diff-files >output.log &&
test_must_be_empty output.log
}
test_expect_success '--mixed refreshes the index' '
# Verify default behavior (without --[no-]refresh or reset.refresh)
test_reset_refreshes_index &&
# With --quiet
test_reset_refreshes_index "" --quiet
'
test_expect_success '--mixed --[no-]refresh sets refresh behavior' '
2022-03-24 02:18:00 +08:00
# Verify that --[no-]refresh controls index refresh
test_reset_refreshes_index "" --refresh &&
2022-03-24 02:18:00 +08:00
! test_reset_refreshes_index "" --no-refresh
'
reset: preserve skip-worktree bit in mixed reset Change `update_index_from_diff` to set `skip-worktree` when applicable for new index entries. When `git reset --mixed <tree-ish>` is run, entries in the index with differences between the pre-reset HEAD and reset <tree-ish> are identified and handled with `update_index_from_diff`. For each file, a new cache entry in inserted into the index, created from the <tree-ish> side of the reset (without changing the working tree). However, the newly-created entry must have `skip-worktree` explicitly set in either of the following scenarios: 1. the file is in the current index and has `skip-worktree` set 2. the file is not in the current index but is outside of a defined sparse checkout definition Not setting the `skip-worktree` bit leads to likely-undesirable results for a user. It causes `skip-worktree` settings to disappear on the "diff"-containing files (but *only* the diff-containing files), leading to those files now showing modifications in `git status`. For example, when running `git reset --mixed` in a sparse checkout, some file entries outside of sparse checkout could show up as deleted, despite the user never deleting anything (and not wanting them on-disk anyway). Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved in a basic `git reset --mixed` scenario and update a failure-documenting test from 19a0acc (t1092: test interesting sparse-checkout scenarios, 2021-01-23) with new expected behavior. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 22:39:17 +08:00
test_expect_success '--mixed preserves skip-worktree' '
echo 123 >>file2 &&
git add file2 &&
git update-index --skip-worktree file2 &&
git reset --mixed HEAD >output &&
test_must_be_empty output &&
cat >expect <<-\EOF &&
Unstaged changes after reset:
M file2
EOF
git update-index --no-skip-worktree file2 &&
git add file2 &&
git reset --mixed HEAD >output &&
test_cmp expect output
'
test_expect_success 'resetting specific path that is unmerged' '
git rm --cached file2 &&
F1=$(git rev-parse HEAD:file1) &&
F2=$(git rev-parse HEAD:file2) &&
F3=$(git rev-parse HEAD:secondfile) &&
{
echo "100644 $F1 1 file2" &&
echo "100644 $F2 2 file2" &&
echo "100644 $F3 3 file2"
} | git update-index --index-info &&
git ls-files -u &&
git reset HEAD file2 &&
test_must_fail git diff --quiet &&
git diff-index --exit-code --cached HEAD
'
Allow "git-reset path" when unambiguous Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
test_expect_success 'disambiguation (1)' '
git reset --hard &&
>secondfile &&
git add secondfile &&
git reset secondfile &&
test_must_fail git diff --quiet -- secondfile &&
Allow "git-reset path" when unambiguous Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
test -z "$(git diff --cached --name-only)" &&
test -f secondfile &&
test_must_be_empty secondfile
Allow "git-reset path" when unambiguous Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
'
test_expect_success 'disambiguation (2)' '
git reset --hard &&
>secondfile &&
git add secondfile &&
rm -f secondfile &&
test_must_fail git reset secondfile &&
test -n "$(git diff --cached --name-only -- secondfile)" &&
test ! -f secondfile
'
test_expect_success 'disambiguation (3)' '
git reset --hard &&
>secondfile &&
git add secondfile &&
rm -f secondfile &&
git reset HEAD secondfile &&
test_must_fail git diff --quiet &&
Allow "git-reset path" when unambiguous Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
test -z "$(git diff --cached --name-only)" &&
test ! -f secondfile
'
test_expect_success 'disambiguation (4)' '
git reset --hard &&
>secondfile &&
git add secondfile &&
rm -f secondfile &&
git reset -- secondfile &&
test_must_fail git diff --quiet &&
Allow "git-reset path" when unambiguous Resetting a selected set of index entries is done with "git reset -- paths" syntax, but we did not allow -- to be omitted even when the command is unambiguous. This updates the command to follow the general rule: * When -- appears, revs come before it, and paths come after it; * When there is no --, earlier ones are revs and the rest are paths, and we need to guess. When lack of -- marker forces us to guess, we protect from user errors and typoes by making sure what we treat as revs do not appear as filenames in the work tree, and what we treat as paths do appear as filenames in the work tree, and by erroring out if that is not the case. We tell the user to disambiguate by using -- in such a case. which is employed elsewhere in the system. When this rule is applied to "reset", because we can have only zero or one rev to the command, the check can be slightly simpler than other programs. We have to check only the first one or two tokens after the command name and options, and when they are: -- A: no explicit rev given; "A" and whatever follows it are paths. A --: explicit rev "A" given and whatever follows the "--" are paths. A B: "A" could be rev or path and we need to guess. "B" could be missing but if exists that (and everything that follows) would be paths. So we apply the guess only in the last case and only to "A" (not "B" and what comes after it). * As long as "A" is unambiguously a path, index entries for "A", "B" (and everything that follows) are reset to the HEAD revision. * If "A" is unambiguously a rev, on the other hand, the index entries for "B" (and everything that follows) are reset to the "A" revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
test -z "$(git diff --cached --name-only)" &&
test ! -f secondfile
'
test_expect_success 'reset with paths accepts tree' '
# for simpler tests, drop last commit containing added files
git reset --hard HEAD^ &&
git reset HEAD^^{tree} -- . &&
git diff --cached HEAD^ --exit-code &&
git diff HEAD --exit-code
'
test_expect_success 'reset -N keeps removed files as intent-to-add' '
echo new-file >new-file &&
git add new-file &&
git reset -N HEAD &&
tree=$(git write-tree) &&
git ls-tree $tree new-file >actual &&
test_must_be_empty actual &&
git diff --name-only >actual &&
echo new-file >expect &&
test_cmp expect actual
'
test_expect_success 'reset --mixed sets up work tree' '
git init mixed_worktree &&
(
cd mixed_worktree &&
test_commit dummy
) &&
git --git-dir=mixed_worktree/.git --work-tree=mixed_worktree reset >actual &&
test_must_be_empty actual
'
parse-options: decouple "--end-of-options" and "--" When we added generic end-of-options support in 51b4594b40 (parse-options: allow --end-of-options as a synonym for "--", 2019-08-06), we made them true synonyms. They both stop option parsing, and they are both returned in the resulting argv if the KEEP_DASHDASH flag is used. The hope was that this would work for all callers: - most generic callers would not pass KEEP_DASHDASH, and so would just do the right thing (stop parsing there) without needing to know anything more. - callers with KEEP_DASHDASH were generally going to rely on setup_revisions(), which knew to handle --end-of-options specially But that turned out miss quite a few cases that pass KEEP_DASHDASH but do their own manual parsing. For example, "git reset", "git checkout", and so on want pass KEEP_DASHDASH so they can support: git reset $revs -- $paths but of course aren't going to actually do a traversal, so they don't call setup_revisions(). And those cases currently get confused by --end-of-options being left in place, like: $ git reset --end-of-options HEAD fatal: option '--end-of-options' must come before non-option arguments We could teach each of these callers to handle the leftover option explicitly. But let's try to be a bit more clever and see if we can solve it centrally in parse-options.c. The bogus assumption here is that KEEP_DASHDASH tells us the caller wants to see --end-of-options in the result. But really, the callers which need to know that --end-of-options was reached are those that may potentially parse more options from argv. In other words, those that pass the KEEP_UNKNOWN_OPT flag. If such a caller is aware of --end-of-options (e.g., because they call setup_revisions() with the result), then this will continue to do the right thing, treating anything after --end-of-options as a non-option. And if the caller is not aware of --end-of-options, they are better off keeping it intact, because either: 1. They are just passing the options along to somebody else anyway, in which case that somebody would need to know about the --end-of-options marker. 2. They are going to parse the remainder themselves, at which point choking on --end-of-options is much better than having it silently removed. The point is to avoid option injection from untrusted command line arguments, and bailing is better than quietly treating the untrusted argument as an option. This fixes bugs with --end-of-options across several commands, but I've focused on two in particular here: - t7102 confirms that "git reset --end-of-options --foo" now works. This checks two things. One, that we no longer barf on "--end-of-options" itself (which previously we did, even if the rev was something vanilla like "HEAD" instead of "--foo"). And two, that we correctly treat "--foo" as a revision rather than an option. This fix applies to any other cases which pass KEEP_DASHDASH but not KEEP_UNKNOWN_OPT, like "git checkout", "git check-attr", "git grep", etc, which would previously choke on "--end-of-options". - t9350 shows the opposite case: fast-export passed KEEP_UNKNOWN_OPT but not KEEP_DASHDASH, but then passed the result on to setup_revisions(). So it never saw --end-of-options, and would erroneously parse "fast-export --end-of-options --foo" as having a "--foo" option. This is now fixed. Note that this does shut the door for callers which want to know if we hit end-of-options, but don't otherwise need to keep unknown opts. The obvious thing here is feeding it to the DWIM verify_filename() machinery. And indeed, this is a problem even for commands which do understand --end-of-options already. For example, without this patch, you get: $ git log --end-of-options --foo fatal: option '--foo' must come before non-option arguments because we refuse to accept "--foo" as a filename (because it starts with a dash) even though we could know that we saw end-of-options. The verify_filename() function simply doesn't accept this extra information. So that is the status quo, and this patch doubles down further on that. Commands like "git reset" have the same problem, but they won't even know that parse-options saw --end-of-options! So even if we fixed verify_filename(), they wouldn't have anything to pass to it. But in practice I don't think this is a big deal. If you are being careful enough to use --end-of-options, then you should also be using "--" to disambiguate and avoid the DWIM behavior in the first place. In other words, doing: git log --end-of-options --this-is-a-rev -- --this-is-a-path works correctly, and will continue to do so. And likewise, with this patch now: git reset --end-of-options --this-is-a-rev -- --this-is-a-path will work, as well. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-07 06:21:45 +08:00
test_expect_success 'reset handles --end-of-options' '
git update-ref refs/heads/--foo HEAD^ &&
git log -1 --format=%s refs/heads/--foo >expect &&
git reset --hard --end-of-options --foo &&
git log -1 --format=%s HEAD >actual &&
test_cmp expect actual
'
test_done