cloning a tree which has detached branch checked out

cloning a tree which has detached branch checked out

[Michael S. Tsirkin]

I have a tree where I checked out a remote, without
creating a local branch, this detaches the HEAD:
# git branch
* (no branch)
  master
#git log|head -1
commit cec64082f689f949a397cb9b39423dc41545fa0e
#git log master..HEAD|head -1
commit cec64082f689f949a397cb9b39423dc41545fa0e


Now if I try to clone it:
#git clone -n lab:/home/mst/scm/linux
Initialized empty Git repository in /home/mst/scm/linux/.git/
remote: Counting objects: 1693446, done.
remote: Compressing objects: 100% (277054/277054), done.
Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
done.
remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
Resolving deltas: 100% (1414353/1414353), done.
error: Trying to write ref HEAD with nonexistant object
cec64082f689f949a397cb9b39423dc41545fa0e
fatal: Cannot update the ref 'HEAD'.

Looks like a bug, doesn't it?

-- 
MST

Re: cloning a tree which has detached branch checked out

[Jakub Narebski]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> I have a tree where I checked out a remote, without
> creating a local branch, this detaches the HEAD:
> # git branch
> * (no branch)
>   master
> #git log|head -1
> commit cec64082f689f949a397cb9b39423dc41545fa0e
> #git log master..HEAD|head -1
> commit cec64082f689f949a397cb9b39423dc41545fa0e
> 
> 
> Now if I try to clone it:
> #git clone -n lab:/home/mst/scm/linux
> Initialized empty Git repository in /home/mst/scm/linux/.git/
> remote: Counting objects: 1693446, done.
> remote: Compressing objects: 100% (277054/277054), done.
> Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
> done.
> remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
> Resolving deltas: 100% (1414353/1414353), done.
> error: Trying to write ref HEAD with nonexistant object
> cec64082f689f949a397cb9b39423dc41545fa0e
> fatal: Cannot update the ref 'HEAD'.
> 
> Looks like a bug, doesn't it?

Which git version?  IIRC there was some bugfix recently in that
area...

-- 
Jakub Narebski

Re: cloning a tree which has detached branch checked out

[Michael S. Tsirkin]

On Tue, Feb 07, 2012 at 02:08:33AM -0800, Jakub Narebski wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > I have a tree where I checked out a remote, without
> > creating a local branch, this detaches the HEAD:
> > # git branch
> > * (no branch)
> >   master
> > #git log|head -1
> > commit cec64082f689f949a397cb9b39423dc41545fa0e
> > #git log master..HEAD|head -1
> > commit cec64082f689f949a397cb9b39423dc41545fa0e
> > 
> > 
> > Now if I try to clone it:
> > #git clone -n lab:/home/mst/scm/linux
> > Initialized empty Git repository in /home/mst/scm/linux/.git/
> > remote: Counting objects: 1693446, done.
> > remote: Compressing objects: 100% (277054/277054), done.
> > Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
> > done.
> > remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
> > Resolving deltas: 100% (1414353/1414353), done.
> > error: Trying to write ref HEAD with nonexistant object
> > cec64082f689f949a397cb9b39423dc41545fa0e
> > fatal: Cannot update the ref 'HEAD'.
> > 
> > Looks like a bug, doesn't it?
> 
> Which git version?  IIRC there was some bugfix recently in that
> area...

Sorry, forgot to mention that. It's pretty recent:
$ git --version
git version 1.7.9.111.gf3fb0


> -- 
> Jakub Narebski

Re: cloning a tree which has detached branch checked out

[Nguyen Thai Ngoc Duy]

On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > #git clone -n lab:/home/mst/scm/linux
>> > ....
>> > error: Trying to write ref HEAD with nonexistant object
>> > cec64082f689f949a397cb9b39423dc41545fa0e
>> > fatal: Cannot update the ref 'HEAD'.
>> >
>> > Looks like a bug, doesn't it?
>>
>> Which git version?  IIRC there was some bugfix recently in that
>> area...
>
> Sorry, forgot to mention that. It's pretty recent:
> $ git --version
> git version 1.7.9.111.gf3fb0

The series that Jakub mentioned is probably nd/clone-detached 5ce2b97,
which is already included in your tree. Does 1.7.9 work?

I tried but it was ok for me. I think ref processing at local probably
goes wrong and does not request commit from HEAD.  If the repo is not
confidential, you can zip it and send me.
-- 
Duy

Re: cloning a tree which has detached branch checked out

[Michael S. Tsirkin]

On Tue, Feb 07, 2012 at 07:57:08PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > #git clone -n lab:/home/mst/scm/linux
> >> > ....
> >> > error: Trying to write ref HEAD with nonexistant object
> >> > cec64082f689f949a397cb9b39423dc41545fa0e
> >> > fatal: Cannot update the ref 'HEAD'.
> >> >
> >> > Looks like a bug, doesn't it?
> >>
> >> Which git version?  IIRC there was some bugfix recently in that
> >> area...
> >
> > Sorry, forgot to mention that. It's pretty recent:
> > $ git --version
> > git version 1.7.9.111.gf3fb0
> 
> The series that Jakub mentioned is probably nd/clone-detached 5ce2b97,
> which is already included in your tree. Does 1.7.9 work?

I'll try that.

> I tried but it was ok for me. I think ref processing at local probably
> goes wrong and does not request commit from HEAD.  If the repo is not
> confidential, you can zip it and send me.

Can't unfortunately :(
Would some verbose logs help?

> -- 
> Duy

Re: cloning a tree which has detached branch checked out

[Nguyen Thai Ngoc Duy]

On Tue, Feb 7, 2012 at 8:02 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> I tried but it was ok for me. I think ref processing at local probably
>> goes wrong and does not request commit from HEAD.  If the repo is not
>> confidential, you can zip it and send me.
>
> Can't unfortunately :(
> Would some verbose logs help?

You can try cloning with GIT_TRACE_PACKET=1. bisect should also help.
-- 
Duy

Re: cloning a tree which has detached branch checked out

[Jeff King]

On Tue, Feb 07, 2012 at 07:57:08PM +0700, Nguyen Thai Ngoc Duy wrote:

> On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > #git clone -n lab:/home/mst/scm/linux
> >> > ....
> >> > error: Trying to write ref HEAD with nonexistant object
> >> > cec64082f689f949a397cb9b39423dc41545fa0e
> >> > fatal: Cannot update the ref 'HEAD'.
> >> >
> >> > Looks like a bug, doesn't it?
> >>
> >> Which git version?  IIRC there was some bugfix recently in that
> >> area...
> >
> > Sorry, forgot to mention that. It's pretty recent:
> > $ git --version
> > git version 1.7.9.111.gf3fb0
> 
> The series that Jakub mentioned is probably nd/clone-detached 5ce2b97,
> which is already included in your tree. Does 1.7.9 work?
> 
> I tried but it was ok for me. I think ref processing at local probably
> goes wrong and does not request commit from HEAD.  If the repo is not
> confidential, you can zip it and send me.

This particular bug should have been fixed before that, even, with my
c1921c1 (clone: always fetch remote HEAD, 2011-06-07). And it is tested
explicitly in t5707, so your series does not regress at least a simple
case. So I think your guess about a subtle error in the local ref
processing is a reasonable one.

-Peff

Re: cloning a tree which has detached branch checked out

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Feb 07, 2012 at 07:57:08PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> >> > #git clone -n lab:/home/mst/scm/linux
>> >> > ....
>> >> > error: Trying to write ref HEAD with nonexistant object
>> >> > cec64082f689f949a397cb9b39423dc41545fa0e
>> >> > fatal: Cannot update the ref 'HEAD'.
>> >> >
>> >> > Looks like a bug, doesn't it?
>> >> ...
>
> This particular bug should have been fixed before that, even, with my
> c1921c1 (clone: always fetch remote HEAD, 2011-06-07). And it is tested
> explicitly in t5707,...

That was my thought when I first saw it.  The failure case was that HEAD
was pointing at something no ref reaches, and clone was only grabbing the
tips of branches, which failed to transfer the history leading to HEAD.

> ... So I think your guess about a subtle error in the local ref
> processing is a reasonable one.

What is funny is "error: Trying to write ref HEAD with nonexistant object".
"git grep -e nonexistant f3fb0" does not register any hit.

Could it be that mysterious "lab:" protocol handler that is misbehaving?

Re: cloning a tree which has detached branch checked out

[Jeff King]

On Tue, Feb 07, 2012 at 09:11:00AM -0800, Junio C Hamano wrote:

> > This particular bug should have been fixed before that, even, with my
> > c1921c1 (clone: always fetch remote HEAD, 2011-06-07). And it is tested
> > explicitly in t5707,...
> [...]
> What is funny is "error: Trying to write ref HEAD with nonexistant object".
> "git grep -e nonexistant f3fb0" does not register any hit.

That misspelling of "nonexistent" was fixed by 7be8b3b (Fix typo:
existant->existent, 2011-06-16), around the same time as my clone patch.
Which really makes me wonder if the OP is accidentally running an old
version of git during the tests.

> >> On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> > #git clone -n lab:/home/mst/scm/linux
> [...]
> Could it be that mysterious "lab:" protocol handler that is misbehaving?

I think you are misreading. It would be "lab::" in that case, no? The
command above should do ssh transport to the machine "lab".

-Peff

Re: cloning a tree which has detached branch checked out

[Michael S. Tsirkin]

On Tue, Feb 07, 2012 at 12:16:04PM -0500, Jeff King wrote:
> On Tue, Feb 07, 2012 at 09:11:00AM -0800, Junio C Hamano wrote:
> 
> > > This particular bug should have been fixed before that, even, with my
> > > c1921c1 (clone: always fetch remote HEAD, 2011-06-07). And it is tested
> > > explicitly in t5707,...
> > [...]
> > What is funny is "error: Trying to write ref HEAD with nonexistant object".
> > "git grep -e nonexistant f3fb0" does not register any hit.
> 
> That misspelling of "nonexistent" was fixed by 7be8b3b (Fix typo:
> existant->existent, 2011-06-16), around the same time as my clone patch.
> Which really makes me wonder if the OP is accidentally running an old
> version of git during the tests.

Double checked and you are right: the box actually runs git 1.7.1.
Rechecked with 1.7.9.GIT and it behaves correctly.

My mistake, sorry about the noise.

-- 
MST