From: Vaclav Hanzl <hanzl@noel.feld.cvut.cz>
Date: Sat, 14 Jun 2008 20:15:11 GMT
Subject: Re: Document clone of clone ... bug??
Message-ID: <20080614.221511.74741328.hanzl@noel.feld.cvut.cz>
In-Reply-To: <20080614143117.GA8640@sigill.intra.peff.net>

> The clone of clone does not have dangling objects; either it sees a ref
> (because it is a branch in the clone) and it grabs the objects, or it
> does not see it, in which case it does not download those objects.

Yes, there should not be a dangling object, but I actually got one. I
was surprised, but I thought it is just an undocumented benign behavior
(optimization overkill - clone rather gets those objects instead of
thinking what it needs). Now I think it may be a bug.

Can someone with deeper knowledge and fresh git please try this:

 rm -rf A B C
 mkdir A B C
 (cd A; mkdir X; cd X; git init; echo x>x; git add x; git commit -m xxx;
  git checkout -b br; echo y>y; git add y; git commit -m yyy;
  git checkout master)
 (cd B; git clone ../A/X)
 (cd C; git clone ../B/X; cd X; git fsck --full)

With my 11 days old version of git, I get:

 dangling commit ...

and 'git show ...' reveals that this commit it that otherwise
(rightfully) lost branch 'br'.

SHA1 is changing when I repeat this (due to dates in reflogs??).

When I omit 'git checkout master', no dangling commit appears. Strange.

Is it my faulty thinking, benign undocumented thing, or a bug?

Vaclav Hanzl