Re: git clone (ssh://) skips detached HEAD

From: Jeff King <peff@peff.net>
Date: Jun 1, 2011, 22:51 UTC
Message-ID: <20110601225128.GB16820@sigill.intra.peff.net>
In-Reply-To: <m31uzdxjf9.fsf@localhost.localdomain>

On Wed, Jun 01, 2011 at 03:42:58PM -0700, Jakub Narebski wrote:

Show 9 quoted lines

> > The reason is that the default refspec on clone is:
> > 
> >   $ git config remote.origin.fetch
> >   +refs/heads/*:refs/remotes/origin/*
> > 
> > And HEAD is not under refs/heads/.
> 
> Hmmm... HEAD is a bit of special case, as HEAD should really land in
> refs/remotes/origin/HEAD from what I understand.

No, that is always supposed to be a symbolic ref. Making it a real ref would be confusing. I don't think fetch should look at HEAD at all; it's outside its refspec. However, clone does treat HEAD specially, and should probably convert the remote's detached HEAD into a local detached HEAD (we already do if it's part of referenced history).

Show 15 quoted lines

> > > git clone ssh://127.0.0.1/`pwd`/test test2
> > > remote: Counting objects: 3, done.
> > > remote: Total 3 (delta 0), reused 0 (delta 0)
> > > Receiving objects: 100% (3/3), done.
> > > error: Trying to write ref HEAD with nonexistant object
> > > 91dbc2403853783f637744c31036f94a66084286
> > > fatal: Cannot update the ref 'HEAD'.
> > 
> > This is quite bad behavior. In addition to the ugly error messages, it
> > actually aborts the clone. So it is impossible to clone a repo with a
> > detached HEAD that is not otherwise referenced.
> 
> It _might_ be the case that the fact that git protocol doesn't have
> mechanism to transfer information about symref, and ends up guessing
> where HEAD points to, bites use here.

No, we already handle that case. If there is a valid HEAD and no ref matches, then we assume it's a detached HEAD. Which makes sense, and the guess is right in this case. The problem is that we didn't fetch the objects for HEAD.

-Peff