How to clone a bare git repo with no commits and get the correct HEAD ref during the clone?

Viewed 138

This answer claims that the issue was fixed in version 1.8.4.3, but I still encounter it in version 2.25.1. It appears to work as expected in version 2.32.0, so I'm not sure when it was actually fixed.

Is there a way to get the expected behavior in git version 2.25.1 using the clone subcommand (without having to checkout/switch branches after cloning)?

Here are reproduction steps:


  1. Initialize a bare repo:
BARE_DIR="$PWD/bare"
WORKING_DIR="$PWD/working"

mkdir -p $BARE_DIR/repo
cd $BARE_DIR/repo
git init --bare
  1. Change the HEAD ref:
git symbolic-ref HEAD refs/heads/very-unlikely-to-be-your-configured-default-branch
  1. Clone a working copy of the repo:
mkdir $WORKING_DIR
cd $WORKING_DIR
git clone $BARE_DIR/repo
cd repo
  1. Check the HEAD ref:
cat .git/HEAD

I expect the output to be:

ref: refs/heads/very-unlikely-to-be-your-configured-default-branch

but instead it's:

ref: refs/heads/master
2 Answers

When there are no commits, there are no branches.

Although Git can, in modern Git, read the default branch name from the other Git, and therefore could create a new clone with the correct ref: refs/heads/name entry, Git 2.25 does not. If it did, the unborn branch in the new clone would match the unborn branch in the bare repository. This is what you'd like. But until Git 2.31.0, Git did not do that.

If you can't upgrade, the solution is to make the repository you're cloning contain at least one commit, so that it can have an infinite number of branch names. Then create at least one branch name in that repository—though, actually, creating that first commit will create one branch name for you—and make its HEAD refer to the one desired branch name.

Is there a way to get the expected behavior in git version 2.25.1 using the clone sub-command (without having to checkout/switch branches after cloning)?

Even it there was a way, that would not always be enough:

"git clone"(man) from a repository with some ref whose HEAD is unborn did not set the HEAD in the resulting repository correctly, which has been corrected with Git 2.38 (Q3 2022).

See commit daf7898 (11 Jul 2022), and commit cc8fcd1, commit 3d8314f, commit f77710c (07 Jul 2022) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit cf92cb2, 19 Jul 2022)

clone: propagate empty remote HEAD even with other branches

Signed-off-by: Jeff King

Unless "--branch" was given, clone generally tries to match the local HEAD to the remote one.
For most repositories, this is easy: the remote tells us which branch HEAD was pointing to, and we call our local checkout() function on that branch.

When cloning an empty repository, it's a little more tricky: we have special code that checks the transport's "unborn" extension, or falls back to our local idea of what the default branch should be.
In either case, we point the new HEAD to that, and set up the branch.* config.

But that leaves one case unhandled: when the remote repository isn't empty, but its HEAD is unborn.
The checkout() function is smart enough to realize we didn't fetch the remote HEAD and it bails with a warning.
But we'll have ignored any information the remote gave us via the unborn extension.
This leads to nonsense outcomes:

  • If the remote has its HEAD pointing to an unborn "foo" and contains another branch "bar", cloning will get branch "bar" but leave the local HEAD pointing at "master" (or whatever our local default is), which is useless.
    The project does not use "master" as a branch.
  • Worse, if the other branch "bar" is instead called "master" (but again, the remote HEAD is not pointing to it), then we end up with a local unborn branch "master", which is not connected to the remote "master" (it shares no history, and there's no branch.* config).

Instead, we should try to use the remote's HEAD, even if its unborn, to be consistent with the other cases.

The reason this case was missed is that cmd_clone() handles empty and non-empty repositories on two different sides of a conditional:

if (we have any refs) {
    fetch refs;
    check for --branch;
    otherwise, try to point our head at remote head;
    otherwise, our head is NULL;
} else {
    check for --branch;
    otherwise, try to use "unborn" extension;
    otherwise, fall back to our default name name;
}

So the smallest change would be to repeat the "unborn" logic at the end of the first block.
But we can note some other overlaps and inconsistencies:

  • both sides have to handle --branch (though note that it's always an error for the empty repo case, since an empty repo by definition does not have a matching branch)
  • the fall back to the default name is much more explicit in the empty-repo case.
    The non-empty case eventually ends up bailing from checkout() with a warning, which produces a similar result, but fails to set up the branch config we do in the empty case.

So let's pull the HEAD setup out of this conditional entirely.
This de-duplicates some of the code and the result is easy to follow, because helper functions like find_ref_by_name() do the right thing even in the empty-repo case (i.e., by returning NULL).

There are two subtleties:

  • for a remote with a detached HEAD, it will advertise an oid for HEAD (which we store in our "remote_head" variable), but we won't find a matching refname (so our "remote_head_points_at" is NULL).
    In this case we make a local detached HEAD to match.
    Right now this happens implicitly by reaching update_head() with a non-NULL remote_head (since we skip all of the unborn-fallback).
    We'll now need to account for it explicitly before doing the fallback.

  • for an empty repo, we issue a warning to the user that they've cloned an empty repo.
    The text of that warning doesn't make sense for a non-empty repo with an unborn HEAD, so we'll have to differentiate the two cases there.
    We could just use different text, but instead let's allow the code to continue down to checkout(), which will issue an appropriate warning, like:

    remote HEAD refers to nonexistent ref, unable to checkout

    Continuing down to checkout() will make it easier to do more fixes on top (see below).

Note that this patch fixes the case where the other side reports an unborn head to us using the protocol extension.
It doesn't fix the case where the other side doesn't tell us, we locally guess "master", and the other side happens to have a "master" which its HEAD doesn't point.
But it doesn't make anything worse there, and it should actually make it easier to fix that problem on top.

Related