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

[Dmitry Potapov <dpotapov@gmail.com>]

On Wed, Apr 16, 2008 at 04:56:08PM +0200, Johannes Sixt wrote:
> 
> 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.

In my experiment, there was no problem with hidden commits and objects
as long as they presented in the original repository. Maybe, it is
because I cloned it as locally using:

   git clone PATH-TO-ORIG-REPO PATH-TO-DEST-REPO

Maybe things would be as you say if I used git://

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

I use git 1.5.5 and I have a script that creates are repo with a hidden
commit and then it cleans the reflog cleaned (as it would be happen after
expiration of gc.reflogExpire). Then I run 'git-repack -f -d -a' and the
hidden commit still presents, but when I run 'git prune' then the hidden
object disappear. You can try it for yourself. Here is the script, I used:

===
#!/bin/sh

set -e

mkdir t5
cd t5
git init

echo 1 > foo
git add foo
git commit -m 'add foo'
R1=$(git rev-parse HEAD)

echo 2 >> foo
git commit -m 'edit foo' -a
R2=$(git rev-parse HEAD)

echo 3 >> foo
git commit -m 'edit foo again' -a
R3=$(git rev-parse HEAD)

set -x
git log
echo "$R3 $R1" > .git/info/grafts
git log
git-fsck --unreachable
: > .git/logs/HEAD
: > .git/logs/refs/heads/master
git-fsck --unreachable
git gc
git-fsck --unreachable


git-repack -f -d -a
git-fsck --unreachable

git prune
git-fsck --unreachable
===

Dmitry