Re: 'HEAD' is not a commit (according to git-checkout)
On Thu, May 21, 2020 at 12:00:00PM -0700, Dana Dahlstrom wrote:
Show 10 quoted lines
> 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
