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
|
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 - &&
|
2022-06-14 19:27:29 +00:00
|
|
|
test_commit $i &&
|
|
|
|
git branch wt-$i &&
|
2022-07-19 18:33:33 +00:00
|
|
|
git branch fake-$i &&
|
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
|
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 &&
|
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 &&
|
2023-10-23 16:06:56 +00:00
|
|
|
grep "cannot delete branch" err || return 1
|
2022-06-14 19:27:29 +00:00
|
|
|
done
|
|
|
|
'
|
|
|
|
|
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 &&
|
2022-06-14 19:27:30 +00:00
|
|
|
|
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 &&
|
2022-06-14 19:27:30 +00:00
|
|
|
|
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
|
2022-06-14 19:27:30 +00:00
|
|
|
'
|
|
|
|
|
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
|
2022-07-19 18:33:34 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success !SANITIZE_LEAK 'refuse to overwrite: worktree in rebase (merge)' '
|
2022-07-19 18:33:33 +00:00
|
|
|
test_when_finished git -C wt-2 rebase --abort &&
|
2022-06-14 19:27:30 +00:00
|
|
|
|
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 &&
|
2022-06-14 19:27:30 +00:00
|
|
|
|
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
|
2022-06-14 19:27:30 +00:00
|
|
|
'
|
|
|
|
|
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 &&
|
2022-07-19 18:33:35 +00:00
|
|
|
|
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 &&
|
2022-07-19 18:33:35 +00:00
|
|
|
|
|
|
|
for i in 3 4
|
|
|
|
do
|
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 ||
|
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' '
|
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
|
|
|
|
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
|
|
|
|
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' '
|
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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
'
|
|
|
|
|
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 ||
|
2022-06-14 19:27:33 +00:00
|
|
|
return 1
|
|
|
|
done
|
|
|
|
'
|
|
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2022-06-14 19:27:29 +00:00
|
|
|
test_done
|