On Wed, 1 Aug 2007, Domenico Andreoli wrote: > > $ git fsck --no-reflogs > dangling blob e5d444e61b834c34710ce8fb5cb176e20e5894e1 > > $ git-ls-tree 70b58535361eb633d44d4f1275af3421ca6a5ed7 > ... > 100644 blob e5d444e61b834c34710ce8fb5cb176e20e5894e1 link_stream.c Have you done clones with stupid protocols (rsync and/or http)? The simplest explanation for this is that since you didn't do "--full" for fsck, then your git-fsck never looked into the pack-files you had. And the tree might well exist in a pack-file, and thus not even looked at by fsck. So try "git fsck --full", and see if that changes the picture. (Usually, you'd never have a pack-file *and* the loose object it points to both at the same time, but especially if you use the dumb transports (rsync and/or http), you'll get pack-files from remotes, and thus you won't have the normal nice behaviour of pack-files being "old state", and loose objects being "new state". The easiest fixup is likely to just do "git gc", which which do a nice repack, and get rid of loose objects that are duplicates of stuff that is also in a pack-file. Linus - 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