development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-27 11:39:22 +00:00
Code Issues Packages Projects Releases Wiki Activity
git/t/t2407-worktree-heads.sh

181 lines
5.5 KiB
Bash
Raw Normal View History

branch: add branch_checked_out() helper The validate_new_branchname() method contains a check to see if a branch is checked out in any non-bare worktree. This is intended to prevent a force push that will mess up an existing checkout. This helper is not suitable to performing just that check, because the method will die() when the branch is checked out instead of returning an error code. Create a new branch_checked_out() helper that performs the most basic form of this check. To ensure we can call branch_checked_out() in a loop with good performance, do a single preparation step that iterates over all worktrees and stores their current HEAD branches in a strmap. The branch_checked_out() helper can then discover these branches using a hash lookup. This helper is currently missing some key functionality. Namely: it doesn't look for active rebases or bisects which mean that the branch is "checked out" even though HEAD doesn't point to that ref. This functionality will be added in a coming change. We could use branch_checked_out() in validate_new_branchname(), but this missing functionality would be a regression. However, we have no tests that cover this case! Add a new test script that will be expanded with these cross-worktree ref updates. The current tests would still pass if we refactored validate_new_branchname() to use this version of branch_checked_out(). The next change will fix that functionality and add the proper test coverage. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:29 +00:00
#!/bin/sh
test_description='test operations trying to overwrite refs at worktree HEAD'
TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
test_expect_success 'setup' '
test_commit init &&
for i in 1 2 3 4
do
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
git checkout -b conflict-$i &&
echo "not I" >$i.t &&
git add $i.t &&
git commit -m "will conflict" &&
git checkout - &&
branch: add branch_checked_out() helper The validate_new_branchname() method contains a check to see if a branch is checked out in any non-bare worktree. This is intended to prevent a force push that will mess up an existing checkout. This helper is not suitable to performing just that check, because the method will die() when the branch is checked out instead of returning an error code. Create a new branch_checked_out() helper that performs the most basic form of this check. To ensure we can call branch_checked_out() in a loop with good performance, do a single preparation step that iterates over all worktrees and stores their current HEAD branches in a strmap. The branch_checked_out() helper can then discover these branches using a hash lookup. This helper is currently missing some key functionality. Namely: it doesn't look for active rebases or bisects which mean that the branch is "checked out" even though HEAD doesn't point to that ref. This functionality will be added in a coming change. We could use branch_checked_out() in validate_new_branchname(), but this missing functionality would be a regression. However, we have no tests that cover this case! Add a new test script that will be expanded with these cross-worktree ref updates. The current tests would still pass if we refactored validate_new_branchname() to use this version of branch_checked_out(). The next change will fix that functionality and add the proper test coverage. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:29 +00:00
test_commit $i &&
git branch wt-$i &&
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
git branch fake-$i &&
branch: add branch_checked_out() helper The validate_new_branchname() method contains a check to see if a branch is checked out in any non-bare worktree. This is intended to prevent a force push that will mess up an existing checkout. This helper is not suitable to performing just that check, because the method will die() when the branch is checked out instead of returning an error code. Create a new branch_checked_out() helper that performs the most basic form of this check. To ensure we can call branch_checked_out() in a loop with good performance, do a single preparation step that iterates over all worktrees and stores their current HEAD branches in a strmap. The branch_checked_out() helper can then discover these branches using a hash lookup. This helper is currently missing some key functionality. Namely: it doesn't look for active rebases or bisects which mean that the branch is "checked out" even though HEAD doesn't point to that ref. This functionality will be added in a coming change. We could use branch_checked_out() in validate_new_branchname(), but this missing functionality would be a regression. However, we have no tests that cover this case! Add a new test script that will be expanded with these cross-worktree ref updates. The current tests would still pass if we refactored validate_new_branchname() to use this version of branch_checked_out(). The next change will fix that functionality and add the proper test coverage. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:29 +00:00
git worktree add wt-$i wt-$i || return 1
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
done &&
# Create a server that updates each branch by one commit
git init server &&
test_commit -C server initial &&
git remote add server ./server &&
for i in 1 2 3 4
do
git -C server checkout -b wt-$i &&
test_commit -C server A-$i || return 1
done &&
for i in 1 2
do
git -C server checkout -b fake-$i &&
test_commit -C server f-$i || return 1
branch: add branch_checked_out() helper The validate_new_branchname() method contains a check to see if a branch is checked out in any non-bare worktree. This is intended to prevent a force push that will mess up an existing checkout. This helper is not suitable to performing just that check, because the method will die() when the branch is checked out instead of returning an error code. Create a new branch_checked_out() helper that performs the most basic form of this check. To ensure we can call branch_checked_out() in a loop with good performance, do a single preparation step that iterates over all worktrees and stores their current HEAD branches in a strmap. The branch_checked_out() helper can then discover these branches using a hash lookup. This helper is currently missing some key functionality. Namely: it doesn't look for active rebases or bisects which mean that the branch is "checked out" even though HEAD doesn't point to that ref. This functionality will be added in a coming change. We could use branch_checked_out() in validate_new_branchname(), but this missing functionality would be a regression. However, we have no tests that cover this case! Add a new test script that will be expanded with these cross-worktree ref updates. The current tests would still pass if we refactored validate_new_branchname() to use this version of branch_checked_out(). The next change will fix that functionality and add the proper test coverage. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:29 +00:00
done
'
test_expect_success 'refuse to overwrite: checked out in worktree' '
for i in 1 2 3 4
do
t2407: fix broken &&-chains in compound statement The breaks in the &&-chain in this test went unnoticed because the "magic exit code 117" &&-chain checker built into test-lib.sh only recognizes broken &&-chains at the top-level; it does not work within `{...}` groups, `(...)` subshells, `$(...)` substitutions, or within bodies of compound statements, such as `if`, `for`, `while`, `case`, etc. Furthermore, `chainlint.sed` detects broken &&-chains only in `(...)` subshells. Thus, the &&-chain breaks in this test fall into the blind spots of the &&-chain linters. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-22 18:26:40 +00:00
test_must_fail git branch -f wt-$i HEAD 2>err &&
branch: use branch_checked_out() when deleting refs This is the last current use of find_shared_symref() that can easily be replaced by branch_checked_out(). The benefit of this switch is that the code is a bit simpler, but also it is faster on repeated calls. The remaining uses of find_shared_symref() are non-trivial to remove, so we probably should not continue in that direction: * builtin/notes.c uses find_shared_symref() with "NOTES_MERGE_REF" instead of "HEAD", so it doesn't have an immediate analogue with branch_checked_out(). Perhaps we should consider extending it to include that symref in addition to HEAD, BISECT_HEAD, and REBASE_HEAD. * receive-pack.c checks to see if a worktree has a checkout for the ref that is being updated. The tricky part is that it can actually decide to update the worktree directly instead of just skipping the update. This all depends on the receive.denyCurrentBranch config option. The implementation currenty cares about receiving the worktree in the result, so the current branch_checked_out() prototype is insufficient currently. This is something to investigate later, though, since a large number of refs could be updated at the same time and using the strmap implementation of branch_checked_out() could be beneficial. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:32 +00:00
grep "cannot force update the branch" err &&
t2407: fix broken &&-chains in compound statement The breaks in the &&-chain in this test went unnoticed because the "magic exit code 117" &&-chain checker built into test-lib.sh only recognizes broken &&-chains at the top-level; it does not work within `{...}` groups, `(...)` subshells, `$(...)` substitutions, or within bodies of compound statements, such as `if`, `for`, `while`, `case`, etc. Furthermore, `chainlint.sed` detects broken &&-chains only in `(...)` subshells. Thus, the &&-chain breaks in this test fall into the blind spots of the &&-chain linters. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-22 18:26:40 +00:00
test_must_fail git branch -D wt-$i 2>err &&
builtin/branch.c: adjust error messages to coding guidelines As per the CodingGuidelines document, it is recommended that error messages such as die(), error() and warning(), should start with a lowercase letter and should not end with a period. This patch adjusts tests to match updated messages. Signed-off-by: Isoken June Ibizugbe <isokenjune@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-23 16:06:56 +00:00
grep "cannot delete branch" err || return 1
branch: add branch_checked_out() helper The validate_new_branchname() method contains a check to see if a branch is checked out in any non-bare worktree. This is intended to prevent a force push that will mess up an existing checkout. This helper is not suitable to performing just that check, because the method will die() when the branch is checked out instead of returning an error code. Create a new branch_checked_out() helper that performs the most basic form of this check. To ensure we can call branch_checked_out() in a loop with good performance, do a single preparation step that iterates over all worktrees and stores their current HEAD branches in a strmap. The branch_checked_out() helper can then discover these branches using a hash lookup. This helper is currently missing some key functionality. Namely: it doesn't look for active rebases or bisects which mean that the branch is "checked out" even though HEAD doesn't point to that ref. This functionality will be added in a coming change. We could use branch_checked_out() in validate_new_branchname(), but this missing functionality would be a regression. However, we have no tests that cover this case! Add a new test script that will be expanded with these cross-worktree ref updates. The current tests would still pass if we refactored validate_new_branchname() to use this version of branch_checked_out(). The next change will fix that functionality and add the proper test coverage. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:29 +00:00
done
'
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_expect_success !SANITIZE_LEAK 'refuse to overwrite: worktree in bisect' '
test_when_finished git -C wt-4 bisect reset &&
branch: check for bisects and rebases The branch_checked_out() helper was added by the previous change, but it used an over-simplified view to check if a branch is checked out. It only focused on the HEAD symref, but ignored whether a bisect or rebase was happening. Teach branch_checked_out() to check for these things, and also add tests to ensure that we do not lose this functionality in the future. Now that this test coverage exists, we can safely refactor validate_new_branchname() to use branch_checked_out(). Note that we need to prepend "refs/heads/" to the 'state.branch' after calling wt_status_check_*(). We also need to duplicate wt->path so the value is not freed at the end of the call. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:30 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
# Set up a bisect so HEAD no longer points to wt-4.
git -C wt-4 bisect start &&
git -C wt-4 bisect bad wt-4 &&
git -C wt-4 bisect good wt-1 &&
branch: check for bisects and rebases The branch_checked_out() helper was added by the previous change, but it used an over-simplified view to check if a branch is checked out. It only focused on the HEAD symref, but ignored whether a bisect or rebase was happening. Teach branch_checked_out() to check for these things, and also add tests to ensure that we do not lose this functionality in the future. Now that this test coverage exists, we can safely refactor validate_new_branchname() to use branch_checked_out(). Note that we need to prepend "refs/heads/" to the 'state.branch' after calling wt_status_check_*(). We also need to duplicate wt->path so the value is not freed at the end of the call. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:30 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_must_fail git branch -f wt-4 HEAD 2>err &&
branch: update the message to refuse touching a branch in-use The "git branch -f" command can refuse to force-update a branch that is used by another worktree. The original rationale for this behaviour was that updating a branch that is checked out in another worktree, without making a matching change to the index and the working tree files in that worktree, will lead to a very confused user. "git diff HEAD" will no longer give a useful patch, because HEAD is a commit unrelated to what the index and the working tree in the worktree were based on, for example. These days, the same mechanism also protects branches that are being rebased or bisected, and the same machanism is expected to be the right place to add more checks, when we decide to protect branches undergoing other kinds of operations. We however forgot to rethink the messaging, which originally said that we are refusing to touch the branch because it is "checked out" elsewhere, when d2ba271a (branch: check for bisects and rebases, 2022-06-14) started to protect branches that are being rebased or bisected. The spirit of the check has always been that we do not want to disrupt the use of the same branch in other worktrees. Let's reword the message slightly to say that the branch is "used by" another worktree, instead of "checked out". We could teach the branch.c:prepare_checked_out_branches() function to remember why it decided that a particular branch needs protecting (i.e. was it because it was checked out? being bisected? something else?) in addition to which worktree the branch was in use, and use that in the error message to say "you cannot force update this branch because it is being bisected in the worktree X", etc., but it is dubious that such extra complexity is worth it. The message already tells which directory the worktree in question is, and it should be just a "chdir" away for the user to find out what state it is in, if the user felt curious enough. So let's not go there yet. Helped-by: Josh Sref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-21 21:53:12 +00:00
grep "cannot force update the branch '\''wt-4'\'' used by worktree at.*wt-4" err
branch: check for bisects and rebases The branch_checked_out() helper was added by the previous change, but it used an over-simplified view to check if a branch is checked out. It only focused on the HEAD symref, but ignored whether a bisect or rebase was happening. Teach branch_checked_out() to check for these things, and also add tests to ensure that we do not lose this functionality in the future. Now that this test coverage exists, we can safely refactor validate_new_branchname() to use branch_checked_out(). Note that we need to prepend "refs/heads/" to the 'state.branch' after calling wt_status_check_*(). We also need to duplicate wt->path so the value is not freed at the end of the call. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:30 +00:00
'
t2407: test branches currently using apply backend The tests in t2407 that verify the branch_checked_out() helper in the case of bisects and rebases were added by 9347303db89 (branch: check for bisects and rebases, 2022-06-08). However, that commit failed to check for rebases that are using the 'apply' backend. Add a test that checks the apply backend. The implementation was already correct here, but it is good to have regression tests before modifying the implementation further. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:34 +00:00
test_expect_success !SANITIZE_LEAK 'refuse to overwrite: worktree in rebase (apply)' '
test_when_finished git -C wt-2 rebase --abort &&
# This will fail part-way through due to a conflict.
test_must_fail git -C wt-2 rebase --apply conflict-2 &&
test_must_fail git branch -f wt-2 HEAD 2>err &&
branch: update the message to refuse touching a branch in-use The "git branch -f" command can refuse to force-update a branch that is used by another worktree. The original rationale for this behaviour was that updating a branch that is checked out in another worktree, without making a matching change to the index and the working tree files in that worktree, will lead to a very confused user. "git diff HEAD" will no longer give a useful patch, because HEAD is a commit unrelated to what the index and the working tree in the worktree were based on, for example. These days, the same mechanism also protects branches that are being rebased or bisected, and the same machanism is expected to be the right place to add more checks, when we decide to protect branches undergoing other kinds of operations. We however forgot to rethink the messaging, which originally said that we are refusing to touch the branch because it is "checked out" elsewhere, when d2ba271a (branch: check for bisects and rebases, 2022-06-14) started to protect branches that are being rebased or bisected. The spirit of the check has always been that we do not want to disrupt the use of the same branch in other worktrees. Let's reword the message slightly to say that the branch is "used by" another worktree, instead of "checked out". We could teach the branch.c:prepare_checked_out_branches() function to remember why it decided that a particular branch needs protecting (i.e. was it because it was checked out? being bisected? something else?) in addition to which worktree the branch was in use, and use that in the error message to say "you cannot force update this branch because it is being bisected in the worktree X", etc., but it is dubious that such extra complexity is worth it. The message already tells which directory the worktree in question is, and it should be just a "chdir" away for the user to find out what state it is in, if the user felt curious enough. So let's not go there yet. Helped-by: Josh Sref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-21 21:53:12 +00:00
grep "cannot force update the branch '\''wt-2'\'' used by worktree at.*wt-2" err
t2407: test branches currently using apply backend The tests in t2407 that verify the branch_checked_out() helper in the case of bisects and rebases were added by 9347303db89 (branch: check for bisects and rebases, 2022-06-08). However, that commit failed to check for rebases that are using the 'apply' backend. Add a test that checks the apply backend. The implementation was already correct here, but it is good to have regression tests before modifying the implementation further. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:34 +00:00
'
test_expect_success !SANITIZE_LEAK 'refuse to overwrite: worktree in rebase (merge)' '
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_when_finished git -C wt-2 rebase --abort &&
branch: check for bisects and rebases The branch_checked_out() helper was added by the previous change, but it used an over-simplified view to check if a branch is checked out. It only focused on the HEAD symref, but ignored whether a bisect or rebase was happening. Teach branch_checked_out() to check for these things, and also add tests to ensure that we do not lose this functionality in the future. Now that this test coverage exists, we can safely refactor validate_new_branchname() to use branch_checked_out(). Note that we need to prepend "refs/heads/" to the 'state.branch' after calling wt_status_check_*(). We also need to duplicate wt->path so the value is not freed at the end of the call. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:30 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
# This will fail part-way through due to a conflict.
test_must_fail git -C wt-2 rebase conflict-2 &&
branch: check for bisects and rebases The branch_checked_out() helper was added by the previous change, but it used an over-simplified view to check if a branch is checked out. It only focused on the HEAD symref, but ignored whether a bisect or rebase was happening. Teach branch_checked_out() to check for these things, and also add tests to ensure that we do not lose this functionality in the future. Now that this test coverage exists, we can safely refactor validate_new_branchname() to use branch_checked_out(). Note that we need to prepend "refs/heads/" to the 'state.branch' after calling wt_status_check_*(). We also need to duplicate wt->path so the value is not freed at the end of the call. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:30 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_must_fail git branch -f wt-2 HEAD 2>err &&
branch: update the message to refuse touching a branch in-use The "git branch -f" command can refuse to force-update a branch that is used by another worktree. The original rationale for this behaviour was that updating a branch that is checked out in another worktree, without making a matching change to the index and the working tree files in that worktree, will lead to a very confused user. "git diff HEAD" will no longer give a useful patch, because HEAD is a commit unrelated to what the index and the working tree in the worktree were based on, for example. These days, the same mechanism also protects branches that are being rebased or bisected, and the same machanism is expected to be the right place to add more checks, when we decide to protect branches undergoing other kinds of operations. We however forgot to rethink the messaging, which originally said that we are refusing to touch the branch because it is "checked out" elsewhere, when d2ba271a (branch: check for bisects and rebases, 2022-06-14) started to protect branches that are being rebased or bisected. The spirit of the check has always been that we do not want to disrupt the use of the same branch in other worktrees. Let's reword the message slightly to say that the branch is "used by" another worktree, instead of "checked out". We could teach the branch.c:prepare_checked_out_branches() function to remember why it decided that a particular branch needs protecting (i.e. was it because it was checked out? being bisected? something else?) in addition to which worktree the branch was in use, and use that in the error message to say "you cannot force update this branch because it is being bisected in the worktree X", etc., but it is dubious that such extra complexity is worth it. The message already tells which directory the worktree in question is, and it should be just a "chdir" away for the user to find out what state it is in, if the user felt curious enough. So let's not go there yet. Helped-by: Josh Sref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-21 21:53:12 +00:00
grep "cannot force update the branch '\''wt-2'\'' used by worktree at.*wt-2" err
branch: check for bisects and rebases The branch_checked_out() helper was added by the previous change, but it used an over-simplified view to check if a branch is checked out. It only focused on the HEAD symref, but ignored whether a bisect or rebase was happening. Teach branch_checked_out() to check for these things, and also add tests to ensure that we do not lose this functionality in the future. Now that this test coverage exists, we can safely refactor validate_new_branchname() to use branch_checked_out(). Note that we need to prepend "refs/heads/" to the 'state.branch' after calling wt_status_check_*(). We also need to duplicate wt->path so the value is not freed at the end of the call. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:30 +00:00
'
rebase: update refs from 'update-ref' commands The previous change introduced the 'git rebase --update-refs' option which added 'update-ref <ref>' commands to the todo list of an interactive rebase. Teach Git to record the HEAD position when reaching these 'update-ref' commands. The ref/before/after triple is stored in the $GIT_DIR/rebase-merge/update-refs file. A previous change parsed this file to avoid having other processes updating the refs in that file while the rebase is in progress. Not only do we update the file when the sequencer reaches these 'update-ref' commands, we then update the refs themselves at the end of the rebase sequence. If the rebase is aborted before this final step, then the refs are not updated. The 'before' value is used to ensure that we do not accidentally obliterate a ref that was updated concurrently (say, by an older version of Git or a third-party tool). Now that the 'git rebase --update-refs' command is implemented to write to the update-refs file, we can remove the fake construction of the update-refs file from a test in t2407-worktree-heads.sh. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:40 +00:00
test_expect_success !SANITIZE_LEAK 'refuse to overwrite: worktree in rebase with --update-refs' '
test_when_finished git -C wt-3 rebase --abort &&
branch: consider refs under 'update-refs' The branch_checked_out() helper helps commands like 'git branch' and 'git fetch' from overwriting refs that are currently checked out in other worktrees. A future update to 'git rebase' will introduce a new '--update-refs' option which will update the local refs that point to commits that are being rebased. To avoid collisions as the rebase completes, we want to make the future data store for these refs to be considered by branch_checked_out(). The data store is a plaintext file inside the 'rebase-merge' directory for that worktree. The file lists refnames followed by two OIDs, each on separate lines. The OIDs will be used to store the original values of the refs and the to-be-written values as the rebase progresses, but can be ignored at the moment. Create a new sequencer_get_update_refs_state() method that parses this file and populates a struct string_list with the ref-OID pairs. We can then use this list to add to the current_checked_out_branches strmap used by branch_checked_out(). To properly navigate to the rebase directory for a given worktree, extract the static strbuf_worktree_gitdir() method to a public API method. We can test that this works without having Git write this file by artificially creating one in our test script, at least until 'git rebase --update-refs' is implemented and we can use it directly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:35 +00:00
rebase: update refs from 'update-ref' commands The previous change introduced the 'git rebase --update-refs' option which added 'update-ref <ref>' commands to the todo list of an interactive rebase. Teach Git to record the HEAD position when reaching these 'update-ref' commands. The ref/before/after triple is stored in the $GIT_DIR/rebase-merge/update-refs file. A previous change parsed this file to avoid having other processes updating the refs in that file while the rebase is in progress. Not only do we update the file when the sequencer reaches these 'update-ref' commands, we then update the refs themselves at the end of the rebase sequence. If the rebase is aborted before this final step, then the refs are not updated. The 'before' value is used to ensure that we do not accidentally obliterate a ref that was updated concurrently (say, by an older version of Git or a third-party tool). Now that the 'git rebase --update-refs' command is implemented to write to the update-refs file, we can remove the fake construction of the update-refs file from a test in t2407-worktree-heads.sh. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:40 +00:00
git branch -f can-be-updated wt-3 &&
test_must_fail git -C wt-3 rebase --update-refs conflict-3 &&
branch: consider refs under 'update-refs' The branch_checked_out() helper helps commands like 'git branch' and 'git fetch' from overwriting refs that are currently checked out in other worktrees. A future update to 'git rebase' will introduce a new '--update-refs' option which will update the local refs that point to commits that are being rebased. To avoid collisions as the rebase completes, we want to make the future data store for these refs to be considered by branch_checked_out(). The data store is a plaintext file inside the 'rebase-merge' directory for that worktree. The file lists refnames followed by two OIDs, each on separate lines. The OIDs will be used to store the original values of the refs and the to-be-written values as the rebase progresses, but can be ignored at the moment. Create a new sequencer_get_update_refs_state() method that parses this file and populates a struct string_list with the ref-OID pairs. We can then use this list to add to the current_checked_out_branches strmap used by branch_checked_out(). To properly navigate to the rebase directory for a given worktree, extract the static strbuf_worktree_gitdir() method to a public API method. We can test that this works without having Git write this file by artificially creating one in our test script, at least until 'git rebase --update-refs' is implemented and we can use it directly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:35 +00:00
for i in 3 4
do
rebase: update refs from 'update-ref' commands The previous change introduced the 'git rebase --update-refs' option which added 'update-ref <ref>' commands to the todo list of an interactive rebase. Teach Git to record the HEAD position when reaching these 'update-ref' commands. The ref/before/after triple is stored in the $GIT_DIR/rebase-merge/update-refs file. A previous change parsed this file to avoid having other processes updating the refs in that file while the rebase is in progress. Not only do we update the file when the sequencer reaches these 'update-ref' commands, we then update the refs themselves at the end of the rebase sequence. If the rebase is aborted before this final step, then the refs are not updated. The 'before' value is used to ensure that we do not accidentally obliterate a ref that was updated concurrently (say, by an older version of Git or a third-party tool). Now that the 'git rebase --update-refs' command is implemented to write to the update-refs file, we can remove the fake construction of the update-refs file from a test in t2407-worktree-heads.sh. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:40 +00:00
test_must_fail git branch -f can-be-updated HEAD 2>err &&
branch: update the message to refuse touching a branch in-use The "git branch -f" command can refuse to force-update a branch that is used by another worktree. The original rationale for this behaviour was that updating a branch that is checked out in another worktree, without making a matching change to the index and the working tree files in that worktree, will lead to a very confused user. "git diff HEAD" will no longer give a useful patch, because HEAD is a commit unrelated to what the index and the working tree in the worktree were based on, for example. These days, the same mechanism also protects branches that are being rebased or bisected, and the same machanism is expected to be the right place to add more checks, when we decide to protect branches undergoing other kinds of operations. We however forgot to rethink the messaging, which originally said that we are refusing to touch the branch because it is "checked out" elsewhere, when d2ba271a (branch: check for bisects and rebases, 2022-06-14) started to protect branches that are being rebased or bisected. The spirit of the check has always been that we do not want to disrupt the use of the same branch in other worktrees. Let's reword the message slightly to say that the branch is "used by" another worktree, instead of "checked out". We could teach the branch.c:prepare_checked_out_branches() function to remember why it decided that a particular branch needs protecting (i.e. was it because it was checked out? being bisected? something else?) in addition to which worktree the branch was in use, and use that in the error message to say "you cannot force update this branch because it is being bisected in the worktree X", etc., but it is dubious that such extra complexity is worth it. The message already tells which directory the worktree in question is, and it should be just a "chdir" away for the user to find out what state it is in, if the user felt curious enough. So let's not go there yet. Helped-by: Josh Sref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-21 21:53:12 +00:00
grep "cannot force update the branch '\''can-be-updated'\'' used by worktree at.*wt-3" err ||
branch: consider refs under 'update-refs' The branch_checked_out() helper helps commands like 'git branch' and 'git fetch' from overwriting refs that are currently checked out in other worktrees. A future update to 'git rebase' will introduce a new '--update-refs' option which will update the local refs that point to commits that are being rebased. To avoid collisions as the rebase completes, we want to make the future data store for these refs to be considered by branch_checked_out(). The data store is a plaintext file inside the 'rebase-merge' directory for that worktree. The file lists refnames followed by two OIDs, each on separate lines. The OIDs will be used to store the original values of the refs and the to-be-written values as the rebase progresses, but can be ignored at the moment. Create a new sequencer_get_update_refs_state() method that parses this file and populates a struct string_list with the ref-OID pairs. We can then use this list to add to the current_checked_out_branches strmap used by branch_checked_out(). To properly navigate to the rebase directory for a given worktree, extract the static strbuf_worktree_gitdir() method to a public API method. We can test that this works without having Git write this file by artificially creating one in our test script, at least until 'git rebase --update-refs' is implemented and we can use it directly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:35 +00:00
return 1
done
'
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
test_expect_success !SANITIZE_LEAK 'refuse to fetch over ref: checked out' '
test_must_fail git fetch server +refs/heads/wt-3:refs/heads/wt-3 2>err &&
grep "refusing to fetch into branch '\''refs/heads/wt-3'\''" err &&
# General fetch into refs/heads/ will fail on first ref,
# so use a generic error message check.
test_must_fail git fetch server +refs/heads/*:refs/heads/* 2>err &&
grep "refusing to fetch into branch" err
'
test_expect_success !SANITIZE_LEAK 'refuse to fetch over ref: worktree in bisect' '
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_when_finished git -C wt-4 bisect reset &&
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
# Set up a bisect so HEAD no longer points to wt-4.
git -C wt-4 bisect start &&
git -C wt-4 bisect bad wt-4 &&
git -C wt-4 bisect good wt-1 &&
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_must_fail git fetch server +refs/heads/wt-4:refs/heads/wt-4 2>err &&
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
grep "refusing to fetch into branch" err
'
test_expect_success !SANITIZE_LEAK 'refuse to fetch over ref: worktree in rebase' '
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_when_finished git -C wt-3 rebase --abort &&
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
# This will fail part-way through due to a conflict.
test_must_fail git -C wt-3 rebase conflict-3 &&
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
t2407: test bisect and rebase as black-boxes The tests added by d2ba271aad0 (branch: check for bisects and rebases, 2022-06-14) modified hidden state to verify the branch_checked_out() helper. While this indeed checks that the method implementation is _as designed_, it doesn't show that it is _correct_. Specifically, if 'git bisect' or 'git rebase' change their back-end for preserving refs, then these tests do not demonstrate that drift as a bug in branch_checked_out(). Modify the tests in t2407 to actually rely on a paused bisect or rebase. This requires adding the !SANITIZE_LEAK prereq for tests using those builtins. The logic is still tested for leaks in the final test which does set up that back-end directly for an error state that should not be possible using Git commands. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:33 +00:00
test_must_fail git fetch server +refs/heads/wt-3:refs/heads/wt-3 2>err &&
fetch: use new branch_checked_out() and add tests When fetching refs from a remote, it is possible that the refspec will cause use to overwrite a ref that is checked out in a worktree. The existing logic in builtin/fetch.c uses a possibly-slow mechanism. Update those sections to use the new, more efficient branch_checked_out() helper. These uses were not previously tested, so add a test case that can be used for these kinds of collisions. There is only one test now, but more tests will be added as other consumers of branch_checked_out() are added. Note that there are two uses in builtin/fetch.c, but only one of the messages is tested. This is because the tested check is run before completing the fetch, and the untested check is not reachable without concurrent updates to the filesystem. Thus, it is beneficial to keep that extra check for the sake of defense-in-depth. However, we should not attempt to test the check, as the effort required is too complicated to be worth the effort. This use in update_local_ref() also requires a change in the error message because we no longer have access to the worktree struct, only the path of the worktree. This error is so rare that making a distinction between the two is not critical. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:31 +00:00
grep "refusing to fetch into branch" err
'
branch: fix branch_checked_out() leaks The branch_checked_out() method populates a strmap linking a refname to a worktree that has that branch checked out. While unlikely, it is possible that a bug or filesystem manipulation could create a scenario where the same ref is checked out in multiple places. Further, there are some states in an interactive rebase where HEAD and REBASE_HEAD point to the same ref, leading to multiple insertions into the strmap. In either case, the strmap_put() method returns the old value which is leaked. Update branch_checked_out() to consume that pointer and free it. Add a test in t2407 that checks this erroneous case. The test "checks itself" by first confirming that the filesystem manipulations it makes trigger the branch_checked_out() logic, and then sets up similar manipulations to make it look like there are multiple worktrees pointing to the same ref. While TEST_PASSES_SANITIZE_LEAK would be helpful to demonstrate the leakage and prevent it in the future, t2407 uses helpers such as 'git clone' that cause the test to fail under that mode. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:33 +00:00
test_expect_success 'refuse to overwrite when in error states' '
test_when_finished rm -rf .git/worktrees/wt-*/rebase-merge &&
test_when_finished rm -rf .git/worktrees/wt-*/BISECT_* &&
# Both branches are currently under rebase.
mkdir -p .git/worktrees/wt-3/rebase-merge &&
touch .git/worktrees/wt-3/rebase-merge/interactive &&
echo refs/heads/fake-1 >.git/worktrees/wt-3/rebase-merge/head-name &&
echo refs/heads/fake-2 >.git/worktrees/wt-3/rebase-merge/onto &&
mkdir -p .git/worktrees/wt-4/rebase-merge &&
touch .git/worktrees/wt-4/rebase-merge/interactive &&
echo refs/heads/fake-2 >.git/worktrees/wt-4/rebase-merge/head-name &&
echo refs/heads/fake-1 >.git/worktrees/wt-4/rebase-merge/onto &&
# Both branches are currently under bisect.
touch .git/worktrees/wt-4/BISECT_LOG &&
echo refs/heads/fake-2 >.git/worktrees/wt-4/BISECT_START &&
touch .git/worktrees/wt-1/BISECT_LOG &&
echo refs/heads/fake-1 >.git/worktrees/wt-1/BISECT_START &&
for i in 1 2
do
test_must_fail git branch -f fake-$i HEAD 2>err &&
branch: update the message to refuse touching a branch in-use The "git branch -f" command can refuse to force-update a branch that is used by another worktree. The original rationale for this behaviour was that updating a branch that is checked out in another worktree, without making a matching change to the index and the working tree files in that worktree, will lead to a very confused user. "git diff HEAD" will no longer give a useful patch, because HEAD is a commit unrelated to what the index and the working tree in the worktree were based on, for example. These days, the same mechanism also protects branches that are being rebased or bisected, and the same machanism is expected to be the right place to add more checks, when we decide to protect branches undergoing other kinds of operations. We however forgot to rethink the messaging, which originally said that we are refusing to touch the branch because it is "checked out" elsewhere, when d2ba271a (branch: check for bisects and rebases, 2022-06-14) started to protect branches that are being rebased or bisected. The spirit of the check has always been that we do not want to disrupt the use of the same branch in other worktrees. Let's reword the message slightly to say that the branch is "used by" another worktree, instead of "checked out". We could teach the branch.c:prepare_checked_out_branches() function to remember why it decided that a particular branch needs protecting (i.e. was it because it was checked out? being bisected? something else?) in addition to which worktree the branch was in use, and use that in the error message to say "you cannot force update this branch because it is being bisected in the worktree X", etc., but it is dubious that such extra complexity is worth it. The message already tells which directory the worktree in question is, and it should be just a "chdir" away for the user to find out what state it is in, if the user felt curious enough. So let's not go there yet. Helped-by: Josh Sref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-21 21:53:12 +00:00
grep "cannot force update the branch '\''fake-$i'\'' used by worktree at" err ||
branch: fix branch_checked_out() leaks The branch_checked_out() method populates a strmap linking a refname to a worktree that has that branch checked out. While unlikely, it is possible that a bug or filesystem manipulation could create a scenario where the same ref is checked out in multiple places. Further, there are some states in an interactive rebase where HEAD and REBASE_HEAD point to the same ref, leading to multiple insertions into the strmap. In either case, the strmap_put() method returns the old value which is leaked. Update branch_checked_out() to consume that pointer and free it. Add a test in t2407 that checks this erroneous case. The test "checks itself" by first confirming that the filesystem manipulations it makes trigger the branch_checked_out() logic, and then sets up similar manipulations to make it look like there are multiple worktrees pointing to the same ref. While TEST_PASSES_SANITIZE_LEAK would be helpful to demonstrate the leakage and prevent it in the future, t2407 uses helpers such as 'git clone' that cause the test to fail under that mode. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:33 +00:00
return 1
done
'
rebase: add --update-refs option When working on a large feature, it can be helpful to break that feature into multiple smaller parts that become reviewed in sequence. During development or during review, a change to one part of the feature could affect multiple of these parts. An interactive rebase can help adjust the multi-part "story" of the branch. However, if there are branches tracking the different parts of the feature, then rebasing the entire list of commits can create commits not reachable from those "sub branches". It can take a manual step to update those branches. Add a new --update-refs option to 'git rebase -i' that adds 'update-ref <ref>' steps to the todo file whenever a commit that is being rebased is decorated with that <ref>. At the very end, the rebase process updates all of the listed refs to the values stored during the rebase operation. Be sure to iterate after any squashing or fixups are placed. Update the branch only after those squashes and fixups are complete. This allows a --fixup commit at the tip of the feature to apply correctly to the sub branch, even if it is fixing up the most-recent commit in that part. This change update the documentation and builtin to accept the --update-refs option as well as updating the todo file with the 'update-ref' commands. Tests are added to ensure that these todo commands are added in the correct locations. This change does _not_ include the actual behavior of tracking the updated refs and writing the new ref values at the end of the rebase process. That is deferred to a later change. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-19 18:33:39 +00:00
. "$TEST_DIRECTORY"/lib-rebase.sh
test_expect_success !SANITIZE_LEAK 'refuse to overwrite during rebase with --update-refs' '
git commit --fixup HEAD~2 --allow-empty &&
(
set_cat_todo_editor &&
test_must_fail git rebase -i --update-refs HEAD~3 >todo &&
! grep "update-refs" todo
) &&
git branch -f allow-update HEAD~2 &&
(
set_cat_todo_editor &&
test_must_fail git rebase -i --update-refs HEAD~3 >todo &&
grep "update-ref refs/heads/allow-update" todo
)
'
# This must be the last test in this file
test_expect_success '$EDITOR and friends are unchanged' '
test_editor_unchanged
'
branch: add branch_checked_out() helper The validate_new_branchname() method contains a check to see if a branch is checked out in any non-bare worktree. This is intended to prevent a force push that will mess up an existing checkout. This helper is not suitable to performing just that check, because the method will die() when the branch is checked out instead of returning an error code. Create a new branch_checked_out() helper that performs the most basic form of this check. To ensure we can call branch_checked_out() in a loop with good performance, do a single preparation step that iterates over all worktrees and stores their current HEAD branches in a strmap. The branch_checked_out() helper can then discover these branches using a hash lookup. This helper is currently missing some key functionality. Namely: it doesn't look for active rebases or bisects which mean that the branch is "checked out" even though HEAD doesn't point to that ref. This functionality will be added in a coming change. We could use branch_checked_out() in validate_new_branchname(), but this missing functionality would be a regression. However, we have no tests that cover this case! Add a new test script that will be expanded with these cross-worktree ref updates. The current tests would still pass if we refactored validate_new_branchname() to use this version of branch_checked_out(). The next change will fix that functionality and add the proper test coverage. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-14 19:27:29 +00:00
test_done
Reference in a new issue Copy permalink