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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 1, 2011, 22:42 UTC
Message-ID: <m31uzdxjf9.fsf@localhost.localdomain>
In-Reply-To: <20110601220518.GA32681@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> On Thu, Jun 02, 2011 at 03:30:37AM +0600, Dmitry Ivankov wrote:
> 
> > For some reason git doesn't try to fetch detached HEAD object if it's
> > not needed by needed heads.
> 
> 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.

[...]

Show 19 quoted lines

> > Steps to reproduce:
> > git init test && cd test
> > touch 1 && git add 1 && git commit -m 123
> > touch 2 && git add 2 && git commit -m 345
> > git reset --hard HEAD^
> > git checkout HEAD@{1}
> > 
> > cd ../
> > 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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git