Jeff King <peff@xxxxxxxx> writes:
> 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.
[...]
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html