summaryrefslogtreecommitdiff
path: root/t/t2018-checkout-branch.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-05-24checkout: improve error messages for -b with extra argumentLibravatar René Scharfe1-1/+1
When we try to create a branch "foo" based on "origin/master" and give git commit -b an extra unsupported argument "bar", it confusingly reports: $ git checkout -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it $ git checkout --track -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it That's wrong, because it very well understands that "origin/master" is supposed to be the start point for the new branch and not "bar". Check if we got a commit and show more fitting messages in that case instead: $ git checkout -b foo origin/master bar fatal: Cannot update paths and switch to branch 'foo' at the same time. $ git checkout --track -b foo origin/master bar fatal: '--track' cannot be used with updating paths Original-patch-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24checkout: add tests for -b and --trackLibravatar René Scharfe1-0/+10
Test git checkout -b with and without --track and demonstrate unexpected error messages when it's given an extra (i.e. unsupported) path argument. In both cases it reports: $ git checkout -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it The problem is that the start point we gave for the new branch is "origin/master" and "bar" is just some extra argument -- it could even be a valid commit, which would make the message even more confusing. We have more fitting error messages in git commit, but get confused; use the text of the rights ones in the tests. Reported-by: Dana Dahlstrom <dahlstrom@google.com> Original-test-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-27unpack-trees: failure to set SKIP_WORKTREE bits always just a warningLibravatar Elijah Newren1-0/+22
Setting and clearing of the SKIP_WORKTREE bit is not only done when users run 'sparse-checkout'; other commands such as 'checkout' also run through unpack_trees() which has logic for handling this special bit. As such, we need to consider how they handle special cases. A couple comparison points should help explain the rationale for changing how unpack_trees() handles these bits: Ignoring sparse checkouts for a moment, if you are switching branches and have dirty changes, it is only considered an error that will prevent the branch switching from being successful if the dirty file happens to be one of the paths with different contents. SKIP_WORKTREE has always been considered advisory; for example, if rebase or merge need or even want to materialize a path as part of their work, they have always been allowed to do so regardless of the SKIP_WORKTREE setting. This has been used for unmerged paths, but it was often used for paths it wasn't needed just because it made the code simpler. It was a best-effort consideration, and when it materialized paths contrary to the SKIP_WORKTREE setting, it was never required to even print a warning message. In the past if you trying to run e.g. 'git checkout' and: 1) you had a path that was materialized and had some dirty changes 2) the path was listed in $GITDIR/info/sparse-checkout 3) this path did not different between the current and target branches then despite the comparison points above, the inability to set SKIP_WORKTREE was treated as a *hard* error that would abort the checkout operation. This is completely inconsistent with how SKIP_WORKTREE is handled elsewhere, and rather annoying for users as leaving the paths materialized in the working copy (with a simple warning) should present no problem at all. Downgrade any errors from inability to toggle the SKIP_WORKTREE bit to a warning and allow the operations to continue. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-27t2018: replace "sha" with "oid"Libravatar Denton Liu1-9/+9
As part of the effort to become more hash-agnostic, replace all instances of "sha" with "oid". Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-27t2018: don't lose return code of git commandsLibravatar Denton Liu1-3/+8
Fix invocations of git commands so their exit codes are not lost within non-assignment command substitutions. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-27t2018: teach do_checkout() to accept `!` argLibravatar Denton Liu1-8/+21
We are running `test_must_fail do_checkout`. However, `test_must_fail` should only be used on git commands. Teach do_checkout() to accept `!` as a potential first argument which will cause the function to expect the "git checkout" to fail. This increases the granularity of the test as, instead of blindly checking that do_checkout() failed, we check that only the specific expected invocation of git fails. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-27t2018: be more discerning when checking for expected exit codesLibravatar Denton Liu1-6/+14
Functions test_dirty_unmergeable() and test_dirty_mergeable() expect git-diff to exit with the specific code 1. However, rather than checking for that value explicitly, they instead negate the exit code. Unfortunately, this negation makes it impossible to distinguish the expected code from some other unexpected non-zero code, for instance, from a segmentation fault. Therefore, be more discerning by checking the exit code explicitly using test_expect_code(). Furthermore, some callers of those functions want to negate the result again, and do so with test_must_fail(). However, test_must_fail() should only be used with git commands. Address this by introducing a couple new tiny helper functions which test the exact condition expected (without the unnecessarily confusing double-negation). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07t2018: improve style of if-statementLibravatar Denton Liu1-1/+2
Convert `[]` to `test` and break if-then into separate lines, both of which bring the style in line with Git's coding guidelines. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07t2018: add space between function name and ()Libravatar Denton Liu1-5/+5
Add a space between the function name and () which brings the style in line with Git's coding guidelines. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27t2018: remove trailing space from test descriptionLibravatar Denton Liu1-1/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07branch: make create_branch accept a merge base revLibravatar Denton Liu1-0/+13
When we ran something like $ git checkout -b test master... it would fail with the message fatal: Not a valid object name: 'master...'. This was caused by the call to `create_branch` where `start_name` is expected to be a valid rev. However, git-checkout allows the branch to be a valid _merge base_ rev (i.e. with a "...") so it was possible for an invalid rev to be passed in. Make `create_branch` accept a merge base rev so that this case does not error out. As a side-effect, teach git-branch how to handle merge base revs as well. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07t2018: cleanup in current testLibravatar Denton Liu1-26/+17
Before, in t2018, if do_checkout failed to create `branch2`, the next test-case would run `git branch -D branch2` but then fail because it was expecting `branch2` to exist, even though it doesn't. As a result, an early failure could cause a cascading failure of tests. Make test-case responsible for cleaning up their own branches so that future tests can start with a sane environment. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-23checkout: fix regression in checkout -b on intitial checkoutLibravatar Ben Peart1-1/+1
When doing a 'checkout -b' do a full checkout including updating the working tree when doing the initial checkout. As the new test involves an filesystem access, do it later in the sequence to give chance to other cheaper tests to leave early. This fixes the regression in behavior caused by fa655d8411 (checkout: optimize "git checkout -b <new_branch>", 2018-08-16). Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-23checkout: add test demonstrating regression with checkout -b on initial commitLibravatar Ben Peart1-0/+9
Commit fa655d8411 (checkout: optimize "git checkout -b <new_branch>", 2018-08-16) introduced an unintentional change in behavior for 'checkout -b' after doing 'clone --no-checkout'. Add a test to demonstrate the changed behavior to be used in a later patch to verify the fix. Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17tests: use test_i18n* functions to suppress false positivesLibravatar Vasco Almeida1-1/+1
The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from plumbing, the test would fail, and the string should be unmarked, since it is not seen by users. Thus, it is productive to not have false positives when running the test under GETTEXT_POISON. This commit replaces normal test functions by their i18n aware variants in use-cases know to be correctly marked for translation, suppressing false positives. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28Allow checkout -B <current-branch> to update the current branchLibravatar Jonathan Nieder1-4/+5
When on master, "git checkout -B master <commit>" is a more natural way to say "git reset --keep <commit>", which was originally invented for the exact purpose of moving to the named commit while keeping the local changes around. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22Show interpreted branch name in error messagesLibravatar Conrad Irwin1-0/+9
Change the error message when doing: "git branch @{-1}", "git checkout -b @{-1}", or "git branch -m foo @{-1}" * was: A branch named '@{-1}' already exists. * now: A branch named 'bar' already exists. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22Prevent force-updating of the current branchLibravatar Conrad Irwin1-0/+8
"git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-01Merge branch 'jc/maint-1.7.3-checkout-describe' into maintLibravatar Junio C Hamano1-0/+11
* jc/maint-1.7.3-checkout-describe: checkout -b <name>: correctly detect existing branch
2011-06-05checkout -b <name>: correctly detect existing branchLibravatar Junio C Hamano1-0/+11
When create a new branch, we fed "refs/heads/<proposed name>" as a string to get_sha1() and expected it to fail when a branch already exists. The right way to check if a ref exists is to check with resolve_ref(). A naïve solution that might appear attractive but does not work is to forbid slashes in get_describe_name() but that will not work. A describe name is is in the form of "ANYTHING-g<short sha1>", and that ANYTHING part comes from a original tag name used in the repository the user ran the describe command. A sick user could have a confusing hierarchical tag whose name is "refs/heads/foobar" (stored as refs/tags/refs/heads/foobar") to generate a describe name "refs/heads/foobar-6-g02ac983", and we should be able to use that name to refer to the object whose name is 02ac983. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-09builtin/checkout: handle -B from detached HEAD correctlyLibravatar Tay Ray Chuan1-0/+6
Ensure that strcmp() isn't called when head is null. Previously we were getting segfaults when checkout -B was done from a detached HEAD. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25builtin/checkout: learn -BLibravatar Tay Ray Chuan1-0/+45
Internally, --track and --orphan still use the 'safe' -b, not -B. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25add tests for checkout -bLibravatar Tay Ray Chuan1-0/+121
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>