development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-11-05 01:58:18 +00:00
Code Issues Projects Releases Packages Wiki Activity
git/t/t7103-reset-bare.sh

75 lines
1.6 KiB
Bash
Raw Permalink Normal View History

git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-31 07:13:52 +00:00
#!/bin/sh
tests: use "git xyzzy" form (t7000 - t7199) Converts tests between t7001-t7103. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 08:59:31 +00:00
test_description='git reset in a bare repository'
leak tests: mark some misc tests as passing with SANITIZE=leak As in 7ff24785cb7 (leak tests: mark some misc tests as passing with SANITIZE=leak, 2021-10-12) continue marking various miscellaneous tests as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-30 22:24:13 +00:00
TEST_PASSES_SANITIZE_LEAK=true
git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-31 07:13:52 +00:00
. ./test-lib.sh
test_expect_success 'setup non-bare' '
echo one >file &&
git add file &&
git commit -m one &&
echo two >file &&
git commit -a -m two
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"hard" reset requires a worktree' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
(cd .git &&
test_must_fail git reset --hard)
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"merge" reset requires a worktree' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
(cd .git &&
test_must_fail git reset --merge)
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"keep" reset requires a worktree' '
(cd .git &&
test_must_fail git reset --keep)
'
test_expect_success '"mixed" reset is ok' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
(cd .git && git reset)
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"soft" reset is ok' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
(cd .git && git reset --soft)
'
reset: unbreak hard resets with GIT_WORK_TREE Commit 952dfc6 tried to tighten the safety valves for doing a "reset --hard" in a bare repository or outside the work tree, but accidentally broke the case for GIT_WORK_TREE. This patch unbreaks it. Most git commands which need a work tree simply use NEED_WORK_TREE in git.c to die before they get to their cmd_* function. Reset, however, only needs a work tree in some cases, and so must handle the work tree itself. The error that 952dfc6 made was to simply forbid certain operations if the work tree was not set up; instead, we need to do the same thing that NEED_WORK_TREE does, which is to call setup_work_tree(). We no longer have to worry about dying in the non-worktree case, as setup_work_tree handles that for us. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-30 08:47:03 +00:00
test_expect_success 'hard reset works with GIT_WORK_TREE' '
mkdir worktree &&
GIT_WORK_TREE=$PWD/worktree GIT_DIR=$PWD/.git git reset --hard &&
test_cmp file worktree/file
'
git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-31 07:13:52 +00:00
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"hard" reset is not allowed in bare' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
test_must_fail git reset --hard HEAD^
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"merge" reset is not allowed in bare' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
test_must_fail git reset --merge HEAD^
'
reset: disallow "reset --keep" outside a work tree It is safer and consistent with "--merge" and "--hard" resets to disallow "git reset --keep" outside a work tree. So let's just do that and add some tests while at it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:26:00 +00:00
test_expect_success '"keep" reset is not allowed in bare' '
test_must_fail git reset --keep HEAD^
'
test_expect_success '"mixed" reset is not allowed in bare' '
reset: improve worktree safety valves The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04 11:11:58 +00:00
test_must_fail git reset --mixed HEAD^
git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-31 07:13:52 +00:00
'
tests: mark tests as passing with SANITIZE=leak This marks tests that have been leak-free since various recent commits, but which were not marked us such when the memory leak was fixed. These were mostly discovered with the "check" mode added in faececa53f9 (test-lib: have the "check" mode for SANITIZE=leak consider leak logs, 2022-07-28). Commits that fixed the last memory leak in these tests. Per narrowing down when they started to pass under SANITIZE=leak with "bisect": - t1022-read-tree-partial-clone.sh: 7e2619d8ff0 (list_objects_filter_options: plug leak of filter_spec strings, 2022-09-08) - t4053-diff-no-index.sh: 07a6f94a6d0 (diff-no-index: release prefixed filenames, 2022-09-07) - t6415-merge-dir-to-symlink.sh: bac92b1f39f (Merge branch 'js/ort-clean-up-after-failed-merge', 2022-08-08). - t5554-noop-fetch-negotiator.sh: 66eede4a37c (prepare_repo_settings(): plug leak of config values, 2022-09-08) - t2012-checkout-last.sh, t7504-commit-msg-hook.sh, t91{15,46,60}-git-svn-*.sh: The in-flight "pw/rebase-no-reflog-action" series, upon which this is based: https://lore.kernel.org/git/pull.1405.git.1667575142.gitgitgadget@gmail.com/ Let's mark all of these as passing with "TEST_PASSES_SANITIZE_LEAK=true", to have it regression tested, including as part of the "linux-leaks" CI job. Additionally, let's remove the "!SANITIZE_LEAK" prerequisite from tests that now pass, these were marked as failing in: - 77e56d55ba6 (diff.c: fix a double-free regression in a18d66cefb, 2022-03-17) - c4d1d526312 (tests: change some 'test $(git) = "x"' to test_cmp, 2022-03-07) These were not spotted with the new "check" mode, but manually, it doesn't cover these sort of prerequisites. There's few enough that we shouldn't bother to automate it. They'll be going away sooner than later. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-08 18:17:37 +00:00
test_expect_success '"soft" reset is allowed in bare' '
git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-31 07:13:52 +00:00
git reset --soft HEAD^ &&
tests: change some 'test $(git) = "x"' to test_cmp Change some of the patterns in the test suite where we were hiding the exit code from "git" by invoking it in a sub-shell within a "test" expression to use temporary files and test_cmp instead. These are not all the occurrences of this anti-pattern, but these in particular hid issues where LSAN was dying, and I'd thus marked these tests as passing under the linux-leaks CI job in past commits with "TEST_PASSES_SANITIZE_LEAK=true". Let's deal with that by either removing that marking, or skipping specific tests under !SANITIZE_LEAK. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:48:52 +00:00
git show --pretty=format:%s >out &&
echo one >expect &&
head -n 1 out >actual &&
test_cmp expect actual
git-reset: refuse to do hard reset in a bare repository It makes no sense since there is no working tree. A soft reset should be fine, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-31 07:13:52 +00:00
'
test_done
Reference in a new issue Copy permalink