Re: git clone (ssh://) skips detached HEAD
- From
Jeff King <peff@peff.net>
- Date
- Jun 1, 2011, 22:05 UTC
- Message-ID
- <20110601220518.GA32681@sigill.intra.peff.net>
- In-Reply-To
- <BANLkTi=xK+hmvGTLnKREScABU=7v_SKqPQ@mail.gmail.com>
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/.
So you can do:
git init test2 && cd test2 git fetch ../test HEAD
if you want. So I don't think it's a bug that we don't fetch it, but...
Show 15 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.
We basically have two choices:
1. Fetch objects for HEAD on clone.
2. Don't checkout a detached HEAD if we don't have the object (or
possibly, don't checkout a detached HEAD at all; we already do
something similar for the case of a HEAD that points to a bogus
branch).I think (2) is more consistent with the refspec we set up, but (1) is probably more convenient to users (and better matches the case where the remote is on a detached HEAD that _does_ point to something we have).
> HEAD seems to be treated in a special way in various places, so > haven't found any easy patch to fix this.
I think it should just be a matter of adding HEAD to the list of things we fetch, although we don't actually want to write it to a ref. I'll take a look.
> And by the way, clone --no-hardlinks test test2 still goes to is_local > codepath and avoids the bug.
Yeah. --no-hardlinks still avoids the git-transport; it just copies instead of hardlinking. I saw you used ssh://localhost above to do your test. You can also use file://$PWD/test to accomplish the same thing without having to run an ssh daemon.
-Peff