Missing blobs after pruning dangling commits

Missing blobs after pruning dangling commits

[Marcin Wiśnicki]

Hello,

recently I had git-fsck report some dangling references:

$ git fsck
dangling commit 9275ee571ead7a75ba57e16ba23155a178459918
dangling commit 047bd63ae82b7540098515467f50562e374edada
dangling commit 839cee3c8e16231e6523ecf8b855ef0863787990
dangling commit f7cb119ea71cb3cc739331f2e26bf3e9fdbba24a
dangling commit 68d41b28f320aff303c5a89b25e2243ad2e526f2
dangling commit effcf50a636d2f08e21706f41eb8ae3c4c577166

This is completely local (isolated) repository.
Based on related FAQ entry ("remove old objects after filter-branch"),
I did this:

$ git reflog expire --expire=0 --all
$ git repack -ad
$ git prune

Unfortunately, now fsck complains:

$ git fsck
missing blob 6d2ddd86d4594f8c756cc31b72d61653255a3161
missing blob 6c537408f0b2226c0b6dae9b0ef0f92710fb25ed
missing blob 2db55c1e39fd80e39eccefc617b852d3ac93abe9
$ git --version
git version 1.7.6.msysgit.0

Is this a bug ?

Also, how can I find where this blob came from. I've tried grepping
all commits in original repo (from backup):

$ gitwhich() {
  git log --all --pretty=format:'%T %H' | while read tree commit; do
    git ls-tree -r $tree | grep -q $1 && echo $commit;
  done
}
$ gitwhich 2db55c1e39fd80e39eccefc617b852d3ac93abe9

but nothing was found.

Re: Missing blobs after pruning dangling commits

[Michael J Gruber]

Marcin Wiśnicki venit, vidit, dixit 22.08.2011 16:29:
> Hello,
> 
> recently I had git-fsck report some dangling references:
> 
> $ git fsck
> dangling commit 9275ee571ead7a75ba57e16ba23155a178459918
> dangling commit 047bd63ae82b7540098515467f50562e374edada
> dangling commit 839cee3c8e16231e6523ecf8b855ef0863787990
> dangling commit f7cb119ea71cb3cc739331f2e26bf3e9fdbba24a
> dangling commit 68d41b28f320aff303c5a89b25e2243ad2e526f2
> dangling commit effcf50a636d2f08e21706f41eb8ae3c4c577166
> 
> This is completely local (isolated) repository.
> Based on related FAQ entry ("remove old objects after filter-branch"),
> I did this:
> 
> $ git reflog expire --expire=0 --all
> $ git repack -ad
> $ git prune
> 
> Unfortunately, now fsck complains:
> 
> $ git fsck
> missing blob 6d2ddd86d4594f8c756cc31b72d61653255a3161
> missing blob 6c537408f0b2226c0b6dae9b0ef0f92710fb25ed
> missing blob 2db55c1e39fd80e39eccefc617b852d3ac93abe9
> $ git --version
> git version 1.7.6.msysgit.0
> 
> Is this a bug ?
> 
> Also, how can I find where this blob came from. I've tried grepping
> all commits in original repo (from backup):
> 
> $ gitwhich() {
>   git log --all --pretty=format:'%T %H' | while read tree commit; do
>     git ls-tree -r $tree | grep -q $1 && echo $commit;
>   done
> }
> $ gitwhich 2db55c1e39fd80e39eccefc617b852d3ac93abe9
> 
> but nothing was found.

Suggestions:

Try git fsck --unreachable.
There may be tree objects which reference those blobs but are not
referenced by a tree or commit. (They should have been pruned, but could
have been stuck in a pack.)

Try repacking again after the prune step.

Could you share that repo or is it private?

Michael

Re: Missing blobs after pruning dangling commits

[Marcin Wiśnicki]

2011/8/23 Michael J Gruber <git@drmicha.warpmail.net>:
> Suggestions:

Neither of them helped, however I've added old packs from backup and did

git fsck
git repack -ad
git reflog expire --expire=0 --all
git repack -ad
git prune
git fsck

And now everything is fine.

Only thing that concerns me is that there are still two packs:
$ ls -la .git/objects/pack/
total 145632
drwxr-xr-x    2 marcin.w Administ     4096 Aug 23 11:42 .
drwxr-xr-x    4 marcin.w Administ    20480 Aug 23 11:47 ..
-rw-r--r--    1 marcin.w Administ   529152 Aug  9 15:01
.tmp-3616-pack-83952e51abdea7469eef06dde2e692e04ba8f9f3.idx
-rw-r--r--    1 marcin.w Administ 149572531 Aug  9 15:01
.tmp-3616-pack-83952e51abdea7469eef06dde2e692e04ba8f9f3.pack
-r--r--r--    1 marcin.w Administ   555724 Aug 23 11:42
pack-3cd1ec9be7cdb31d8eac4404c249edf9c1654937.idx
-r--r--r--    1 marcin.w Administ 147570858 Aug 23 11:42
pack-3cd1ec9be7cdb31d8eac4404c249edf9c1654937.pack

Both files have identical ACLs but pack-3cd1.. has dos attribute
"readonly". Toggling this attribute on any file does not seem to have
an effect on git repack. Both packs are present in
.git/objects/info/packs.
Deleting it by hand followed by repack -ad and fsck seems to work
though, which means it was redundant yet not removed by repack.

> Could you share that repo or is it private?

Unfortunately I can't.