git/t/t2024-checkout-dwim.sh

351 lines
9.4 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='checkout <branch>
Ensures that checkout on an unborn branch does what the user expects'
. ./test-lib.sh
# Is the current branch "refs/heads/$1"?
test_branch () {
printf "%s\n" "refs/heads/$1" >expect.HEAD &&
git symbolic-ref HEAD >actual.HEAD &&
test_cmp expect.HEAD actual.HEAD
}
# Is branch "refs/heads/$1" set to pull from "$2/$3"?
test_branch_upstream () {
printf "%s\n" "$2" "refs/heads/$3" >expect.upstream &&
{
git config "branch.$1.remote" &&
git config "branch.$1.merge"
} >actual.upstream &&
test_cmp expect.upstream actual.upstream
}
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean () {
git status -uno --porcelain >status.actual &&
test_must_be_empty status.actual
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
}
test_expect_success 'setup' '
test_commit my_main &&
git init repo_a &&
(
cd repo_a &&
test_commit a_main &&
git checkout -b foo &&
test_commit a_foo &&
git checkout -b bar &&
checkout: don't revert file on ambiguous tracking branches For easier understanding, here are the existing good scenarios: 1) Have *no* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will create local branch foo, see [1] and 1) Have *a* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will complain, see [3] This patch prevents the following scenario: 1) Have *a* file 'foo', *no* local branch 'foo' and *multiple* remote branches 'foo' 2) `git checkout foo` will successfully... revert contents of file `foo`! That is, adding another remote suddenly changes behavior significantly, which is a surprise at best and could go unnoticed by user at worst. Please see [3] which gives some real world complaints. To my understanding, fix in [3] overlooked the case of multiple remotes, and the whole behavior of falling back to reverting file was never intended: [1] introduces the unexpected behavior. Before, there was fallback from not-a-ref to pathspec. This is reasonable fallback. After, there is another fallback from ambiguous-remote to pathspec. I understand that it was a copy&paste oversight. [2] noticed the unexpected behavior but chose to semi-document it instead of forbidding, because the goal of the patch series was focused on something else. [3] adds `die()` when there is ambiguity between branch and file. The case of multiple tracking branches is seemingly overlooked. The new behavior: if there is no local branch and multiple remote candidates, just die() and don't try reverting file whether it exists (prevents surprise) or not (improves error message). [1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18) https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/ [2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05) https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/ [3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13) https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/ Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
test_commit a_bar &&
git checkout -b ambiguous_branch_and_file &&
test_commit a_ambiguous_branch_and_file
) &&
git init repo_b &&
(
cd repo_b &&
test_commit b_main &&
git checkout -b foo &&
test_commit b_foo &&
git checkout -b baz &&
checkout: don't revert file on ambiguous tracking branches For easier understanding, here are the existing good scenarios: 1) Have *no* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will create local branch foo, see [1] and 1) Have *a* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will complain, see [3] This patch prevents the following scenario: 1) Have *a* file 'foo', *no* local branch 'foo' and *multiple* remote branches 'foo' 2) `git checkout foo` will successfully... revert contents of file `foo`! That is, adding another remote suddenly changes behavior significantly, which is a surprise at best and could go unnoticed by user at worst. Please see [3] which gives some real world complaints. To my understanding, fix in [3] overlooked the case of multiple remotes, and the whole behavior of falling back to reverting file was never intended: [1] introduces the unexpected behavior. Before, there was fallback from not-a-ref to pathspec. This is reasonable fallback. After, there is another fallback from ambiguous-remote to pathspec. I understand that it was a copy&paste oversight. [2] noticed the unexpected behavior but chose to semi-document it instead of forbidding, because the goal of the patch series was focused on something else. [3] adds `die()` when there is ambiguity between branch and file. The case of multiple tracking branches is seemingly overlooked. The new behavior: if there is no local branch and multiple remote candidates, just die() and don't try reverting file whether it exists (prevents surprise) or not (improves error message). [1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18) https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/ [2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05) https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/ [3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13) https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/ Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
test_commit b_baz &&
git checkout -b ambiguous_branch_and_file &&
test_commit b_ambiguous_branch_and_file
) &&
git remote add repo_a repo_a &&
git remote add repo_b repo_b &&
git config remote.repo_b.fetch \
"+refs/heads/*:refs/remotes/other_b/*" &&
git fetch --all
'
test_expect_success 'checkout of non-existing branch fails' '
git checkout -B main &&
test_might_fail git branch -D xyzzy &&
test_must_fail git checkout xyzzy &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_must_fail git rev-parse --verify refs/heads/xyzzy &&
test_branch main
'
test_expect_success 'checkout of branch from multiple remotes fails #1' '
git checkout -B main &&
test_might_fail git branch -D foo &&
test_must_fail git checkout foo &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_must_fail git rev-parse --verify refs/heads/foo &&
test_branch main
'
checkout: don't revert file on ambiguous tracking branches For easier understanding, here are the existing good scenarios: 1) Have *no* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will create local branch foo, see [1] and 1) Have *a* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will complain, see [3] This patch prevents the following scenario: 1) Have *a* file 'foo', *no* local branch 'foo' and *multiple* remote branches 'foo' 2) `git checkout foo` will successfully... revert contents of file `foo`! That is, adding another remote suddenly changes behavior significantly, which is a surprise at best and could go unnoticed by user at worst. Please see [3] which gives some real world complaints. To my understanding, fix in [3] overlooked the case of multiple remotes, and the whole behavior of falling back to reverting file was never intended: [1] introduces the unexpected behavior. Before, there was fallback from not-a-ref to pathspec. This is reasonable fallback. After, there is another fallback from ambiguous-remote to pathspec. I understand that it was a copy&paste oversight. [2] noticed the unexpected behavior but chose to semi-document it instead of forbidding, because the goal of the patch series was focused on something else. [3] adds `die()` when there is ambiguity between branch and file. The case of multiple tracking branches is seemingly overlooked. The new behavior: if there is no local branch and multiple remote candidates, just die() and don't try reverting file whether it exists (prevents surprise) or not (improves error message). [1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18) https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/ [2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05) https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/ [3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13) https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/ Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
test_expect_success 'when arg matches multiple remotes, do not fallback to interpreting as pathspec' '
# create a file with name matching remote branch name
git checkout -b t_ambiguous_branch_and_file &&
>ambiguous_branch_and_file &&
git add ambiguous_branch_and_file &&
git commit -m "ambiguous_branch_and_file" &&
# modify file to verify that it will not be touched by checkout
test_when_finished "git checkout -- ambiguous_branch_and_file" &&
echo "file contents" >ambiguous_branch_and_file &&
cp ambiguous_branch_and_file expect &&
test_must_fail git checkout ambiguous_branch_and_file 2>err &&
test_i18ngrep "matched multiple (2) remote tracking branches" err &&
# file must not be altered
test_cmp expect ambiguous_branch_and_file
'
checkout: add advice for ambiguous "checkout <branch>" As the "checkout" documentation describes: If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to [...] <remote>/<branch. This is a really useful feature. The problem is that when you add another remote (e.g. a fork), git won't find a unique branch name anymore, and will instead print this unhelpful message: $ git checkout master error: pathspec 'master' did not match any file(s) known to git Now it will, on my git.git checkout, print: $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> Note that the "error: pathspec[...]" message is still printed. This is because whatever else checkout may have tried earlier, its final fallback is to try to resolve the argument as a path. E.g. in this case: $ ./git --exec-path=$PWD checkout master pu error: pathspec 'master' did not match any file(s) known to git. error: pathspec 'pu' did not match any file(s) known to git. There we don't print the "hint:" implicitly due to earlier logic around the DWIM fallback. That fallback is only used if it looks like we have one argument that might be a branch. I can't think of an intrinsic reason for why we couldn't in some future change skip printing the "error: pathspec[...]" error. However, to do so we'd need to pass something down to checkout_paths() to make it suppress printing an error on its own, and for us to be confident that we're not silencing cases where those errors are meaningful. I don't think that's worth it since determining whether that's the case could easily change due to future changes in the checkout logic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
test_expect_success 'checkout of branch from multiple remotes fails with advice' '
git checkout -B main &&
checkout: add advice for ambiguous "checkout <branch>" As the "checkout" documentation describes: If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to [...] <remote>/<branch. This is a really useful feature. The problem is that when you add another remote (e.g. a fork), git won't find a unique branch name anymore, and will instead print this unhelpful message: $ git checkout master error: pathspec 'master' did not match any file(s) known to git Now it will, on my git.git checkout, print: $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> Note that the "error: pathspec[...]" message is still printed. This is because whatever else checkout may have tried earlier, its final fallback is to try to resolve the argument as a path. E.g. in this case: $ ./git --exec-path=$PWD checkout master pu error: pathspec 'master' did not match any file(s) known to git. error: pathspec 'pu' did not match any file(s) known to git. There we don't print the "hint:" implicitly due to earlier logic around the DWIM fallback. That fallback is only used if it looks like we have one argument that might be a branch. I can't think of an intrinsic reason for why we couldn't in some future change skip printing the "error: pathspec[...]" error. However, to do so we'd need to pass something down to checkout_paths() to make it suppress printing an error on its own, and for us to be confident that we're not silencing cases where those errors are meaningful. I don't think that's worth it since determining whether that's the case could easily change due to future changes in the checkout logic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
test_might_fail git branch -D foo &&
test_must_fail git checkout foo 2>stderr &&
test_branch main &&
checkout: add advice for ambiguous "checkout <branch>" As the "checkout" documentation describes: If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to [...] <remote>/<branch. This is a really useful feature. The problem is that when you add another remote (e.g. a fork), git won't find a unique branch name anymore, and will instead print this unhelpful message: $ git checkout master error: pathspec 'master' did not match any file(s) known to git Now it will, on my git.git checkout, print: $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> Note that the "error: pathspec[...]" message is still printed. This is because whatever else checkout may have tried earlier, its final fallback is to try to resolve the argument as a path. E.g. in this case: $ ./git --exec-path=$PWD checkout master pu error: pathspec 'master' did not match any file(s) known to git. error: pathspec 'pu' did not match any file(s) known to git. There we don't print the "hint:" implicitly due to earlier logic around the DWIM fallback. That fallback is only used if it looks like we have one argument that might be a branch. I can't think of an intrinsic reason for why we couldn't in some future change skip printing the "error: pathspec[...]" error. However, to do so we'd need to pass something down to checkout_paths() to make it suppress printing an error on its own, and for us to be confident that we're not silencing cases where those errors are meaningful. I don't think that's worth it since determining whether that's the case could easily change due to future changes in the checkout logic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
status_uno_is_clean &&
test_i18ngrep "^hint: " stderr &&
test_must_fail git -c advice.checkoutAmbiguousRemoteBranchName=false \
checkout foo 2>stderr &&
test_branch main &&
checkout: add advice for ambiguous "checkout <branch>" As the "checkout" documentation describes: If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to [...] <remote>/<branch. This is a really useful feature. The problem is that when you add another remote (e.g. a fork), git won't find a unique branch name anymore, and will instead print this unhelpful message: $ git checkout master error: pathspec 'master' did not match any file(s) known to git Now it will, on my git.git checkout, print: $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> Note that the "error: pathspec[...]" message is still printed. This is because whatever else checkout may have tried earlier, its final fallback is to try to resolve the argument as a path. E.g. in this case: $ ./git --exec-path=$PWD checkout master pu error: pathspec 'master' did not match any file(s) known to git. error: pathspec 'pu' did not match any file(s) known to git. There we don't print the "hint:" implicitly due to earlier logic around the DWIM fallback. That fallback is only used if it looks like we have one argument that might be a branch. I can't think of an intrinsic reason for why we couldn't in some future change skip printing the "error: pathspec[...]" error. However, to do so we'd need to pass something down to checkout_paths() to make it suppress printing an error on its own, and for us to be confident that we're not silencing cases where those errors are meaningful. I don't think that's worth it since determining whether that's the case could easily change due to future changes in the checkout logic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
status_uno_is_clean &&
test_i18ngrep ! "^hint: " stderr
'
test_expect_success PERL 'checkout -p with multiple remotes does not print advice' '
git checkout -B main &&
test_might_fail git branch -D foo &&
checkout & worktree: introduce checkout.defaultRemote Introduce a checkout.defaultRemote setting which can be used to designate a remote to prefer (via checkout.defaultRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch. I want this because it's very handy to use this workflow to checkout a repository and create a topic branch, then get back to a "master" as retrieved from upstream: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git checkout master ) That will output: Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' But as soon as a new remote is added (e.g. just to inspect something from someone else) the DWIMery goes away: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git remote add avar git@github.com:avar/tbdiff.git && git fetch avar && git checkout master ) Will output (without the advice output added earlier in this series): error: pathspec 'master' did not match any file(s) known to git. The new checkout.defaultRemote config allows me to say that whenever that ambiguity comes up I'd like to prefer "origin", and it'll still work as though the only remote I had was "origin". Also adjust the advice.checkoutAmbiguousRemoteBranchName message to mention this new config setting to the user, the full output on my git.git is now (the last paragraph is new): $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> hint: hint: If you'd like to always have checkouts of an ambiguous <name> prefer hint: one remote, e.g. the 'origin' remote, consider setting hint: checkout.defaultRemote=origin in your config. I considered splitting this into checkout.defaultRemote and worktree.defaultRemote, but it's probably less confusing to break our own rules that anything shared between config should live in core.* than have two config settings, and I couldn't come up with a short name under core.* that made sense (core.defaultRemoteForCheckout?). See also 70c9ac2f19 ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"", 2009-10-18) which introduced this DWIM feature to begin with, and 4e85333197 ("worktree: make add <path> <branch> dwim", 2017-11-26) which added it to git-worktree. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:49 +00:00
git checkout -p foo 2>stderr &&
test_i18ngrep ! "^hint: " stderr &&
status_uno_is_clean
'
test_expect_success 'checkout of branch from multiple remotes succeeds with checkout.defaultRemote #1' '
git checkout -B main &&
checkout & worktree: introduce checkout.defaultRemote Introduce a checkout.defaultRemote setting which can be used to designate a remote to prefer (via checkout.defaultRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch. I want this because it's very handy to use this workflow to checkout a repository and create a topic branch, then get back to a "master" as retrieved from upstream: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git checkout master ) That will output: Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' But as soon as a new remote is added (e.g. just to inspect something from someone else) the DWIMery goes away: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git remote add avar git@github.com:avar/tbdiff.git && git fetch avar && git checkout master ) Will output (without the advice output added earlier in this series): error: pathspec 'master' did not match any file(s) known to git. The new checkout.defaultRemote config allows me to say that whenever that ambiguity comes up I'd like to prefer "origin", and it'll still work as though the only remote I had was "origin". Also adjust the advice.checkoutAmbiguousRemoteBranchName message to mention this new config setting to the user, the full output on my git.git is now (the last paragraph is new): $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> hint: hint: If you'd like to always have checkouts of an ambiguous <name> prefer hint: one remote, e.g. the 'origin' remote, consider setting hint: checkout.defaultRemote=origin in your config. I considered splitting this into checkout.defaultRemote and worktree.defaultRemote, but it's probably less confusing to break our own rules that anything shared between config should live in core.* than have two config settings, and I couldn't come up with a short name under core.* that made sense (core.defaultRemoteForCheckout?). See also 70c9ac2f19 ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"", 2009-10-18) which introduced this DWIM feature to begin with, and 4e85333197 ("worktree: make add <path> <branch> dwim", 2017-11-26) which added it to git-worktree. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:49 +00:00
status_uno_is_clean &&
test_might_fail git branch -D foo &&
git -c checkout.defaultRemote=repo_a checkout foo &&
status_uno_is_clean &&
test_branch foo &&
test_cmp_rev remotes/repo_a/foo HEAD &&
test_branch_upstream foo repo_a foo
checkout: add advice for ambiguous "checkout <branch>" As the "checkout" documentation describes: If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to [...] <remote>/<branch. This is a really useful feature. The problem is that when you add another remote (e.g. a fork), git won't find a unique branch name anymore, and will instead print this unhelpful message: $ git checkout master error: pathspec 'master' did not match any file(s) known to git Now it will, on my git.git checkout, print: $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> Note that the "error: pathspec[...]" message is still printed. This is because whatever else checkout may have tried earlier, its final fallback is to try to resolve the argument as a path. E.g. in this case: $ ./git --exec-path=$PWD checkout master pu error: pathspec 'master' did not match any file(s) known to git. error: pathspec 'pu' did not match any file(s) known to git. There we don't print the "hint:" implicitly due to earlier logic around the DWIM fallback. That fallback is only used if it looks like we have one argument that might be a branch. I can't think of an intrinsic reason for why we couldn't in some future change skip printing the "error: pathspec[...]" error. However, to do so we'd need to pass something down to checkout_paths() to make it suppress printing an error on its own, and for us to be confident that we're not silencing cases where those errors are meaningful. I don't think that's worth it since determining whether that's the case could easily change due to future changes in the checkout logic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
'
test_expect_success 'checkout of branch from a single remote succeeds #1' '
git checkout -B main &&
test_might_fail git branch -D bar &&
git checkout bar &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_branch bar &&
test_cmp_rev remotes/repo_a/bar HEAD &&
test_branch_upstream bar repo_a bar
'
test_expect_success 'checkout of branch from a single remote succeeds #2' '
git checkout -B main &&
test_might_fail git branch -D baz &&
git checkout baz &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_branch baz &&
test_cmp_rev remotes/other_b/baz HEAD &&
test_branch_upstream baz repo_b baz
'
test_expect_success '--no-guess suppresses branch auto-vivification' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D bar &&
test_must_fail git checkout --no-guess bar &&
test_must_fail git rev-parse --verify refs/heads/bar &&
test_branch main
'
test_expect_success 'checkout.guess = false suppresses branch auto-vivification' '
git checkout -B main &&
status_uno_is_clean &&
test_might_fail git branch -D bar &&
test_config checkout.guess false &&
test_must_fail git checkout bar &&
test_must_fail git rev-parse --verify refs/heads/bar &&
test_branch main
'
test_expect_success 'setup more remotes with unconventional refspecs' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
git init repo_c &&
(
cd repo_c &&
test_commit c_main &&
git checkout -b bar &&
test_commit c_bar &&
git checkout -b spam &&
test_commit c_spam
) &&
git init repo_d &&
(
cd repo_d &&
test_commit d_main &&
git checkout -b baz &&
test_commit d_baz &&
git checkout -b eggs &&
test_commit d_eggs
) &&
git remote add repo_c repo_c &&
git config remote.repo_c.fetch \
"+refs/heads/*:refs/remotes/extra_dir/repo_c/extra_dir/*" &&
git remote add repo_d repo_d &&
git config remote.repo_d.fetch \
"+refs/heads/*:refs/repo_d/*" &&
git fetch --all
'
checkout: Use remote refspecs when DWIMming tracking branches The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 21:52:01 +00:00
test_expect_success 'checkout of branch from multiple remotes fails #2' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D bar &&
test_must_fail git checkout bar &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_must_fail git rev-parse --verify refs/heads/bar &&
test_branch main
'
checkout: Use remote refspecs when DWIMming tracking branches The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 21:52:01 +00:00
test_expect_success 'checkout of branch from multiple remotes fails #3' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D baz &&
test_must_fail git checkout baz &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_must_fail git rev-parse --verify refs/heads/baz &&
test_branch main
'
checkout: Use remote refspecs when DWIMming tracking branches The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 21:52:01 +00:00
test_expect_success 'checkout of branch from a single remote succeeds #3' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D spam &&
git checkout spam &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_branch spam &&
test_cmp_rev refs/remotes/extra_dir/repo_c/extra_dir/spam HEAD &&
test_branch_upstream spam repo_c spam
'
branch.c: Validate tracking branches with refspecs instead of refs/remotes/* The current code for validating tracking branches (e.g. the argument to the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the potential locations for tracking branches. This works with the refspecs created by "git clone" or "git remote add", but is suboptimal in other cases: - If "refs/remotes/foo/bar" exists without any association to a remote (i.e. there is no remote named "foo", or no remote with a refspec that matches "refs/remotes/foo/bar"), then it is impossible to set up a valid upstream config that tracks it. Currently, the code defaults to using "refs/remotes/foo/bar" from repo "." as the upstream, which works, but is probably not what the user had in mind when running "git branch baz --track foo/bar". - If the user has tweaked the fetch refspec for a remote to put its remote-tracking branches outside of refs/remotes/*, e.g. by running git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*" then the current code will refuse to use its remote-tracking branches as --track arguments, since they do not match refs/remotes/*. This patch removes the "refs/remotes/*" requirement for upstream branches, and replaces it with explicit checking of the refspecs for each remote to determine whether a given --track argument is a valid remote-tracking branch. This solves both of the above problems, since the matching refspec guarantees that there is a both a remote name and a remote branch name that can be used for the upstream config. However, this means that refs located within refs/remotes/* without a corresponding remote/refspec will no longer be usable as upstreams. The few existing tests which depended on this behavioral quirk has already been fixed in the preceding patches. This patch fixes the last remaining test failure in t2024-checkout-dwim. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 21:52:05 +00:00
test_expect_success 'checkout of branch from a single remote succeeds #4' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D eggs &&
git checkout eggs &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_branch eggs &&
test_cmp_rev refs/repo_d/eggs HEAD &&
test_branch_upstream eggs repo_d eggs
'
test_expect_success 'checkout of branch with a file having the same name fails' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D spam &&
>spam &&
test_must_fail git checkout spam &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_must_fail git rev-parse --verify refs/heads/spam &&
test_branch main
'
test_expect_success 'checkout of branch with a file in subdir having the same name fails' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D spam &&
>spam &&
mkdir sub &&
mv spam sub/spam &&
test_must_fail git -C sub checkout spam &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_must_fail git rev-parse --verify refs/heads/spam &&
test_branch main
'
test_expect_success 'checkout <branch> -- succeeds, even if a file with the same name exists' '
git checkout -B main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_might_fail git branch -D spam &&
>spam &&
git checkout spam -- &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
test_branch spam &&
test_cmp_rev refs/remotes/extra_dir/repo_c/extra_dir/spam HEAD &&
test_branch_upstream spam repo_c spam
'
test_expect_success 'loosely defined local base branch is reported correctly' '
git checkout main &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
git branch strict &&
git branch loose &&
git commit --allow-empty -m "a bit more" &&
test_config branch.strict.remote . &&
test_config branch.loose.remote . &&
test_config branch.strict.merge refs/heads/main &&
test_config branch.loose.merge main &&
t2024: fix loose/strict local base branch DWIM test Test 'loosely defined local base branch is reported correctly' in t2024-checkout-dwim.sh, which was introduced in [1] compares output of two invocations of "git checkout", invoked with two different branches named "strict" and "loose". As per description in [1], the test is validating that output of tracking information for these two branches. This tracking information is printed to standard output: Your branch is behind 'main' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch) The test assumes that the names of the two branches (strict and loose) are in that output, and pipes the output through sed to replace names of the branches with "BRANCHNAME". Command "git checkout", however, outputs the branch name to standard error, not standard output -- see message "Switched to branch '%s'\n" in function "update_refs_for_switch" in "builtin/checkout.c". This means that the two invocations of sed do nothing. Redirect both the standard output and the standard error of "git checkout" for these assertions. Ensure that compared files have the string "BRANCHNAME". In a series of piped commands, only the return code of the last command is used. Thus, all other commands will have their return codes masked. Avoid piping of output of git directly into sed to preserve the exit status code of "git checkout", while we're here. [1] 05e73682cd (checkout: report upstream correctly even with loosely defined branch.*.merge, 2014-10-14) Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-08 20:54:50 +00:00
git checkout strict >expect.raw 2>&1 &&
sed -e "s/strict/BRANCHNAME/g" <expect.raw >expect &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
t2024: fix loose/strict local base branch DWIM test Test 'loosely defined local base branch is reported correctly' in t2024-checkout-dwim.sh, which was introduced in [1] compares output of two invocations of "git checkout", invoked with two different branches named "strict" and "loose". As per description in [1], the test is validating that output of tracking information for these two branches. This tracking information is printed to standard output: Your branch is behind 'main' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch) The test assumes that the names of the two branches (strict and loose) are in that output, and pipes the output through sed to replace names of the branches with "BRANCHNAME". Command "git checkout", however, outputs the branch name to standard error, not standard output -- see message "Switched to branch '%s'\n" in function "update_refs_for_switch" in "builtin/checkout.c". This means that the two invocations of sed do nothing. Redirect both the standard output and the standard error of "git checkout" for these assertions. Ensure that compared files have the string "BRANCHNAME". In a series of piped commands, only the return code of the last command is used. Thus, all other commands will have their return codes masked. Avoid piping of output of git directly into sed to preserve the exit status code of "git checkout", while we're here. [1] 05e73682cd (checkout: report upstream correctly even with loosely defined branch.*.merge, 2014-10-14) Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-08 20:54:50 +00:00
git checkout loose >actual.raw 2>&1 &&
sed -e "s/loose/BRANCHNAME/g" <actual.raw >actual &&
checkout tests: index should be clean after dwim checkout Assert that whenever there's a DWIM checkout that the index should be clean afterwards, in addition to the correct branch being checked-out. The way the DWIM checkout code in checkout.[ch] works is by looping over all remotes, and for each remote trying to find if a given reference name only exists on that remote, or if it exists anywhere else. This is done by starting out with a `unique = 1` tracking variable in a struct shared by the entire loop, which will get set to `0` if the data reference is not unique. Thus if we find a match we know the dst_oid member of tracking_name_data must be correct, since it's associated with the only reference on the only remote that could have matched our query. But if there was ever a mismatch there for some reason we might end up with the correct branch checked out, but at the wrong oid, which would show whatever the difference between the two staged in the index (checkout branch A, stage changes from the state of branch B). So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'", 2013-04-21) to always assert that "status" is clean after we run "checkout", that's being done with "-uno" because there's going to be some untracked files related to the test itself which we don't care about. In all these tests (DWIM or otherwise) we start with a clean index, so these tests are asserting that that's still the case after the "checkout", failed or otherwise. Then if we ever run into this sort of regression, either in the existing code or with a new feature, we'll know. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:42 +00:00
status_uno_is_clean &&
t2024: fix loose/strict local base branch DWIM test Test 'loosely defined local base branch is reported correctly' in t2024-checkout-dwim.sh, which was introduced in [1] compares output of two invocations of "git checkout", invoked with two different branches named "strict" and "loose". As per description in [1], the test is validating that output of tracking information for these two branches. This tracking information is printed to standard output: Your branch is behind 'main' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch) The test assumes that the names of the two branches (strict and loose) are in that output, and pipes the output through sed to replace names of the branches with "BRANCHNAME". Command "git checkout", however, outputs the branch name to standard error, not standard output -- see message "Switched to branch '%s'\n" in function "update_refs_for_switch" in "builtin/checkout.c". This means that the two invocations of sed do nothing. Redirect both the standard output and the standard error of "git checkout" for these assertions. Ensure that compared files have the string "BRANCHNAME". In a series of piped commands, only the return code of the last command is used. Thus, all other commands will have their return codes masked. Avoid piping of output of git directly into sed to preserve the exit status code of "git checkout", while we're here. [1] 05e73682cd (checkout: report upstream correctly even with loosely defined branch.*.merge, 2014-10-14) Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-08 20:54:50 +00:00
grep BRANCHNAME actual &&
test_cmp expect actual
'
checkout: disambiguate dwim tracking branches and local files When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is that frotz must not exist as a file. But when the user comes to expect "git checkout frotz" to create the branch "frotz" and there happens to be a file named "frotz", git's silently reverting "frotz" file content is not helping. This is reported in Git mailing list [2] and even used as an example of "Git is bad" elsewhere [3]. We normally try to do the right thing, but when there are multiple "right things" to do, it's best to leave it to the user to decide. Check this case, ask the user to to disambiguate: - "git checkout -- foo" will check out path "foo" - "git checkout foo --" will dwim and create branch "foo" [4] For users who do not want dwim, use --no-guess. It's useless in this particular case because "git checkout --no-guess foo --" will just fail. But it could be used by scripts. [1] 70c9ac2f19 (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" - 2009-10-18) [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/ [3] https://news.ycombinator.com/item?id=18230655 [4] a047fafc78 (checkout: allow dwim for branch creation for "git checkout $branch --" - 2013-10-18) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13 17:52:26 +00:00
test_expect_success 'reject when arg could be part of dwim branch' '
git remote add foo file://non-existent-place &&
git update-ref refs/remotes/foo/dwim-arg HEAD &&
echo foo >dwim-arg &&
git add dwim-arg &&
echo bar >dwim-arg &&
test_must_fail git checkout dwim-arg &&
test_must_fail git rev-parse refs/heads/dwim-arg -- &&
grep bar dwim-arg
'
test_expect_success 'disambiguate dwim branch and checkout path (1)' '
git update-ref refs/remotes/foo/dwim-arg1 HEAD &&
echo foo >dwim-arg1 &&
git add dwim-arg1 &&
echo bar >dwim-arg1 &&
git checkout -- dwim-arg1 &&
test_must_fail git rev-parse refs/heads/dwim-arg1 -- &&
grep foo dwim-arg1
'
test_expect_success 'disambiguate dwim branch and checkout path (2)' '
git update-ref refs/remotes/foo/dwim-arg2 HEAD &&
echo foo >dwim-arg2 &&
git add dwim-arg2 &&
echo bar >dwim-arg2 &&
git checkout dwim-arg2 -- &&
git rev-parse refs/heads/dwim-arg2 -- &&
grep bar dwim-arg2
'
test_done