Re: fsck --full is Ok, but clones are not, "missing commits"?!

[Johannes Sixt <j.sixt@viscovery.net>]

Dmitry Potapov schrieb:
> On Wed, Apr 16, 2008 at 03:22:04PM +0200, Johannes Sixt wrote:
>> Brian Foster schrieb:
>>> Dmitry Potapov <dpotapov@gmail.com> correctly deduced:
>>>>  I suspect your original git repository has info/grafts
>>> hi Dmitry,
>>>
>>>  bingo!  YES, it does:
>> ...
>>>  the goal is to put things into a sane state so any new
>>>  clones are healthy.  there's only one(?) existing clone,
>>>  which may or may not be(? become?) an issue.
>> Just move info/grafts out of the way and you *may* be all set. Don't
>> delete it - there might be a reason that the file exists.
> 
> I believe that parts of history hidden by info/grafts are removed now,
> otherwise git clone would not have problems to clone this repository.

No. The reason why git clone'd repositories have problems is that
git-upload-pack sends a pack that does not contain the hidden objects; but
since the cloned repository doesn't have the info/grafts, it tries to look
up the hidden, now missing, objects, and fails.

>> - The repository is broken. Then 'git repack -f -d -a' was done while the
>> grafts were in effect (and obviously the grafts had hidden parts of the
>> history, which are now no longer available).
> 
> Actually, 'git repack -f -d -a' does not remove hidden parts of the
> history (because 'git prune-packed' does not remove hidden parts), but
> 'git prune' does remove hidden parts. I believe 'git prune' relies on
> 'git-fsck --unreachable', which outputs hidden parts as unreachable.
> Perhaps, git-fsck should be corrected, so it will not treat hidden as
> unreachable, because anything what is hidden is still reachable for
> anyone who is trying to clone the repository.

Actually, no. The trouble is that *all* tools obey grafts. Hence,
git-repack -f -d -a will remove the hidden objects. But a subsequent fsck
won't notice, because it *also* obeys the grafts. git prune will remove
hidden objects only as long as they are loose; if they are already packed,
then only a repack -f will remove them.

Here's a thread with a proposal by Linus how to improve the situation, but
nobody came along and implemented it:

http://thread.gmane.org/gmane.comp.version-control.git/37744/focus=37908

-- Hannes