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

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Apr 16, 2008, 14:25 UTC
Message-ID: <20080416142551.GB3133@dpotapov.dyndns.org>
In-Reply-To: <4805FD7C.5000206@viscovery.net>

On Wed, Apr 16, 2008 at 03:22:04PM +0200, Johannes Sixt wrote:

Show 14 quoted lines

> 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. So the best option now is only to turn the "fake" history to the real one using git filter-branch as you wrote.

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

Dmitry