> 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 -- 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
