Re: 'HEAD' is not a commit (according to git-checkout)

[Jeff King <peff@peff.net>]

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