git-commit-vandalism/t/t2015-checkout-unborn.sh

66 lines
1.5 KiB
Bash
Raw Normal View History

checkout: do not imply "-f" on unborn branches When checkout sees that HEAD points to a non-existent ref, it currently acts as if "-f" was given; this behavior dates back to 5a03e7f, which enabled checkout from unborn branches in the shell version of "git-checkout". The reasoning given is to avoid the code path which tries to merge the tree contents. When checkout was converted to C, this code remained intact. The unfortunate side effect of this strategy is that the "force" code path will overwrite working tree and index state that may be precious to the user. Instead of enabling "force", this patch uses the normal "merge" codepath for an unborn branch, but substitutes the empty tree for the "old" commit. This means that in the absence of an index, any files in the working tree will be treated as untracked files, and a checkout which would overwrite them is aborted. Similarly, any paths in the index will be merged with an empty entry as the base, meaning that unless the new branch's content is identical to what's in the index, there will be a conflict and the checkout will be aborted. The user is then free to correct the situation or proceed with "-f" as appropriate. This patch also removes the "warning: you are on a branch yet to be born" message. Its function was to warn the user that we were enabling the "-f" option. Since we are no longer doing that, there is no reason for the user to care whether we are switching away from an unborn branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-25 05:03:16 +02:00
#!/bin/sh
test_description='checkout from unborn branch'
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 00:44:19 +01:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
2022-04-13 22:01:48 +02:00
TEST_PASSES_SANITIZE_LEAK=true
checkout: do not imply "-f" on unborn branches When checkout sees that HEAD points to a non-existent ref, it currently acts as if "-f" was given; this behavior dates back to 5a03e7f, which enabled checkout from unborn branches in the shell version of "git-checkout". The reasoning given is to avoid the code path which tries to merge the tree contents. When checkout was converted to C, this code remained intact. The unfortunate side effect of this strategy is that the "force" code path will overwrite working tree and index state that may be precious to the user. Instead of enabling "force", this patch uses the normal "merge" codepath for an unborn branch, but substitutes the empty tree for the "old" commit. This means that in the absence of an index, any files in the working tree will be treated as untracked files, and a checkout which would overwrite them is aborted. Similarly, any paths in the index will be merged with an empty entry as the base, meaning that unless the new branch's content is identical to what's in the index, there will be a conflict and the checkout will be aborted. The user is then free to correct the situation or proceed with "-f" as appropriate. This patch also removes the "warning: you are on a branch yet to be born" message. Its function was to warn the user that we were enabling the "-f" option. Since we are no longer doing that, there is no reason for the user to care whether we are switching away from an unborn branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-25 05:03:16 +02:00
. ./test-lib.sh
test_expect_success 'setup' '
mkdir parent &&
(
cd parent &&
git init &&
echo content >file &&
git add file &&
git commit -m base
checkout: do not imply "-f" on unborn branches When checkout sees that HEAD points to a non-existent ref, it currently acts as if "-f" was given; this behavior dates back to 5a03e7f, which enabled checkout from unborn branches in the shell version of "git-checkout". The reasoning given is to avoid the code path which tries to merge the tree contents. When checkout was converted to C, this code remained intact. The unfortunate side effect of this strategy is that the "force" code path will overwrite working tree and index state that may be precious to the user. Instead of enabling "force", this patch uses the normal "merge" codepath for an unborn branch, but substitutes the empty tree for the "old" commit. This means that in the absence of an index, any files in the working tree will be treated as untracked files, and a checkout which would overwrite them is aborted. Similarly, any paths in the index will be merged with an empty entry as the base, meaning that unless the new branch's content is identical to what's in the index, there will be a conflict and the checkout will be aborted. The user is then free to correct the situation or proceed with "-f" as appropriate. This patch also removes the "warning: you are on a branch yet to be born" message. Its function was to warn the user that we were enabling the "-f" option. Since we are no longer doing that, there is no reason for the user to care whether we are switching away from an unborn branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-25 05:03:16 +02:00
) &&
git fetch parent main:origin
checkout: do not imply "-f" on unborn branches When checkout sees that HEAD points to a non-existent ref, it currently acts as if "-f" was given; this behavior dates back to 5a03e7f, which enabled checkout from unborn branches in the shell version of "git-checkout". The reasoning given is to avoid the code path which tries to merge the tree contents. When checkout was converted to C, this code remained intact. The unfortunate side effect of this strategy is that the "force" code path will overwrite working tree and index state that may be precious to the user. Instead of enabling "force", this patch uses the normal "merge" codepath for an unborn branch, but substitutes the empty tree for the "old" commit. This means that in the absence of an index, any files in the working tree will be treated as untracked files, and a checkout which would overwrite them is aborted. Similarly, any paths in the index will be merged with an empty entry as the base, meaning that unless the new branch's content is identical to what's in the index, there will be a conflict and the checkout will be aborted. The user is then free to correct the situation or proceed with "-f" as appropriate. This patch also removes the "warning: you are on a branch yet to be born" message. Its function was to warn the user that we were enabling the "-f" option. Since we are no longer doing that, there is no reason for the user to care whether we are switching away from an unborn branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-25 05:03:16 +02:00
'
test_expect_success 'checkout from unborn preserves untracked files' '
echo precious >expect &&
echo precious >file &&
test_must_fail git checkout -b new origin &&
test_cmp expect file
'
test_expect_success 'checkout from unborn preserves index contents' '
echo precious >expect &&
echo precious >file &&
git add file &&
test_must_fail git checkout -b new origin &&
test_cmp expect file &&
git show :file >file &&
test_cmp expect file
'
test_expect_success 'checkout from unborn merges identical index contents' '
echo content >file &&
git add file &&
git checkout -b new origin
'
test_expect_success 'checking out another branch from unborn state' '
git checkout --orphan newroot &&
git checkout -b anothername &&
test_must_fail git show-ref --verify refs/heads/newroot &&
git symbolic-ref HEAD >actual &&
echo refs/heads/anothername >expect &&
test_cmp expect actual
'
test_expect_success 'checking out in a newly created repo' '
test_create_repo empty &&
(
cd empty &&
git symbolic-ref HEAD >expect &&
test_must_fail git checkout &&
git symbolic-ref HEAD >actual &&
test_cmp expect actual
)
'
checkout: do not imply "-f" on unborn branches When checkout sees that HEAD points to a non-existent ref, it currently acts as if "-f" was given; this behavior dates back to 5a03e7f, which enabled checkout from unborn branches in the shell version of "git-checkout". The reasoning given is to avoid the code path which tries to merge the tree contents. When checkout was converted to C, this code remained intact. The unfortunate side effect of this strategy is that the "force" code path will overwrite working tree and index state that may be precious to the user. Instead of enabling "force", this patch uses the normal "merge" codepath for an unborn branch, but substitutes the empty tree for the "old" commit. This means that in the absence of an index, any files in the working tree will be treated as untracked files, and a checkout which would overwrite them is aborted. Similarly, any paths in the index will be merged with an empty entry as the base, meaning that unless the new branch's content is identical to what's in the index, there will be a conflict and the checkout will be aborted. The user is then free to correct the situation or proceed with "-f" as appropriate. This patch also removes the "warning: you are on a branch yet to be born" message. Its function was to warn the user that we were enabling the "-f" option. Since we are no longer doing that, there is no reason for the user to care whether we are switching away from an unborn branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-25 05:03:16 +02:00
test_done