threads / discuss / 28192

Missing blobs after pruning dangling commits

Subject: Missing blobs after pruning dangling commits

## tl;dr

3 messages between Aug 22, 2011 and Aug 23, 2011.

replies: 2people: 2as markdown or json

Marcin Wiśnicki· Aug 22, 2011, 14:29 UTC · lore

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.

Michael J Gruber· Aug 23, 2011, 09:29 UTC · re: Marcin Wiśnicki · lore

Re: Missing blobs after pruning dangling commits

Marcin Wiśnicki venit, vidit, dixit 22.08.2011 16:29:

Show 42 quoted lines

> 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

Marcin Wiśnicki· Aug 23, 2011, 10:16 UTC · re: Michael J Gruber · lore

Re: Missing blobs after pruning dangling commits

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.