On Thu, May 21, 2020 at 12:00:00PM -0700, Dana Dahlstrom wrote: > What did you do before the bug happened? (Steps to reproduce your issue) > > $ git clone https://github.com/githubtraining/hellogitworld.git > $ cd hellogitworld > $ git checkout -b work -t master HEAD > fatal: 'HEAD' is not a commit and a branch 'work' cannot be created from it > $ git show -s --oneline > ef7bebf (HEAD -> master, origin/master, origin/HEAD) Fix groupId […] > $ git checkout -b work -t master ef7bebf > fatal: 'ef7bebf' is not a commit and a branch 'work' cannot be created from it Thanks for a complete reproduction. There are a few things going on here. The "-t" option doesn't take an argument; it's a boolean that says "track the branch we started from". So "master" is taken as the start-point, and "HEAD" is tacked onto the end. I.e., equivalent to: git checkout -b work master HEAD That error message is wrong and misleading. It looks like what happens is that we parse "master" as the start-point. And then we try to treat remaining options (i.e., "HEAD") as a pathspec. That fails, because there's no such path. But then instead of saying "hey, HEAD isn't a pathspec" we try to be clever: /* * Try to give more helpful suggestion. * new_branch && argc > 1 will be caught later. */ if (opts->new_branch && argc == 1) die(_("'%s' is not a commit and a branch '%s' cannot be created from it"), argv[0], opts->new_branch); We know we're making a new branch and there's one argument, so we assume that it didn't get parsed earlier as a start-point. But that misses the fact that if we _did_ parse a start-point, it would have been removed from argv, and our "single argument" is actually the former second-argument. Something like this works: diff --git a/builtin/checkout.c b/builtin/checkout.c index e9d111bb83..6559ac666b 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1553,6 +1553,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix, { struct branch_info new_branch_info; int parseopt_flags = 0; + int got_start_point = 0; memset(&new_branch_info, 0, sizeof(new_branch_info)); opts->overwrite_ignore = 1; @@ -1661,6 +1662,8 @@ static int checkout_main(int argc, const char **argv, const char *prefix, !opts->new_branch; int n = parse_branchname_arg(argc, argv, dwim_ok, &new_branch_info, opts, &rev); + if (n) + got_start_point = 1; argv += n; argc -= n; } else if (!opts->accept_ref && opts->from_treeish) { @@ -1689,7 +1692,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix, * Try to give more helpful suggestion. * new_branch && argc > 1 will be caught later. */ - if (opts->new_branch && argc == 1) + if (opts->new_branch && !got_start_point && argc == 1) die(_("'%s' is not a commit and a branch '%s' cannot be created from it"), argv[0], opts->new_branch); to produce: $ git checkout -b work -t master HEAD fatal: '--track' cannot be used with updating paths $ git checkout -b work master HEAD fatal: Cannot update paths and switch to branch 'work' at the same time. which are both correct. I wonder if there's a more elegant way to do it, though (probably not, as there's definitely some heuristic parsing going on to determine which checkout mode we're in; the new switch/restore alternatives don't suffer as much from this). > What did you expect to happen? (Expected behavior) > > I expected a new branch named 'work' to be created and checked out, > pointing to commit ef7bebf and with upstream branch set to 'master'. So getting back to your actual goal: you can't do what you want with a single checkout command. I think: git checkout -b work HEAD git branch --set-upstream-to=master -Peff
