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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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.
Which could be evil without resumable clone on a big repo.
git clone --bare will work though.

> 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).
I like (2) a bit more too, and give a hint about explicit HEAD fetching.

> 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.
I tried to hack it through via adding HEAD:HEADtmp static const
refspec to remote.{h,c}
and hit "Ignoring funny ref 'HEAD' locally" in remote.c:get_fetch_map,
commented out that ignore and got:

error: unable to resolve reference HEAD: No such file or directory
fatal: Cannot lock the ref 'HEAD'.

from builtin/clone.c:
...
                        const char *head = skip_prefix(our_head_points_at->name,
                                                       "refs/heads/");

                        update_ref(reflog_msg.buf, "HEAD",
                                   our_head_points_at->old_sha1,
                                   NULL, 0, DIE_ON_ERR);
...
afaik from gdb HEAD ended up being a symlink to "" ref or so.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]