On Wed, Jun 01, 2011 at 03:42:58PM -0700, Jakub Narebski wrote: > > 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). > > > 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 -- 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