2

When I run:

git verify-pack -v .git\objects\pack\pack-*.idx

one of the lines in the output contains:

651302358b781ab60f364416272e1c35107c974f blob   23980089 23987383 699599322

But if I try to lookup that blob with:

git rev-list --all --objects | grep 651302358b781ab60f364416272e1c35107c974f

or:

 git rev-list --all --reflog --objects | grep 651302358b781ab60f364416272e1c35107c974f

I just get an empty result. Should I not be able to look up any blobs returned by verify-pack?

Based on below I have tried to: create a fresh clone, run git repack run git gc but same result.

u123
  • 15,603
  • 58
  • 186
  • 303

3 Answers3

2

The object may be abandoned, i.e., its last reference(s), whatever they were, are now gone. Because the object is in a pack file, however, it cannot simply be removed. Git must build an entirely new pack.

If you use git repack to build new pack files, any unreferenced objects will be omitted from the new packs. (Note that git gc will do this automatically. However, .keep files may keep the old packs around, if you have created .keep files.)

Edit: as jthill points out in a comment, you must repack with -a or -A to consolidate older packs. While automatic git gc will supply -A in some cases, it's only when the number of pack files exceeds gc.autoPackLimit, which defaults to 50.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • I did try with git gc but it had no effect, still git verify-pack finds the blob that cannot be looked up with rev-list. And git repack gives "Nothing new to pack". I also tried to clone again, same "ghost" object exists. – u123 Jun 09 '16 at 20:37
  • Perhaps it's referenced from a reflog entry. Try `git rev-list --all --reflogs` for the lookup step (keeping `--objects` as well). Although, if it shows up on initial `clone`, that's a bit odd, since clone does not copy reflogs. – torek Jun 09 '16 at 20:39
  • $ git rev-list --all --reflogs --objects | grep 651302358b781ab60f364416272e1c35107c974f does not work. Seems rev-list does not know --reflogs option – u123 Jun 09 '16 at 20:46
  • Oops, sorry, typo: `--reflog` (singular), not `--reflogs` (plural). – torek Jun 09 '16 at 20:48
  • I don't know what else to try at this point, but I will be curious to see what is going on. – torek Jun 09 '16 at 21:13
  • repack's manpage mentions you need `-a` or `-A` to go dig through the past. – jthill Jun 09 '16 at 21:41
  • @jthill: aha, and `git gc` only supplies `-A` if the pack count exceeds `gc.autoPackLimit`. According to git-config(1), the default is 50 packs. – torek Jun 09 '16 at 22:30
0

I found this at the bottom of git help stash, to find unreferenced commits.

git fsck --unreachable |
grep commit | cut -d\  -f3 |
xargs git log --merges --no-walk --grep=WIP
Gregg
  • 2,444
  • 1
  • 12
  • 21
0

First, I would check if that reference is still in that idx file after

git gc
git repack -Ad      # kills in-pack garbage
git prune           # kills loose garbage

Use Git 2.32 (Q2 2021) considering:

See commit 14e7b83 (19 Mar 2021), commit 2a15964, commit 13d746a, commit dab3247, commit f25e33c (05 Mar 2021), and commit 0fabafd, commit 339bce2, commit c9fff00, commit f62312e (22 Feb 2021) by Taylor Blau (ttaylorr).
See commit ccae01c (05 Mar 2021) by Junio C Hamano (gitster).
See commit 20b031f, commit 6325da1, commit fbf20ae, commit 60bb5f2 (22 Feb 2021) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 2744383, 24 Mar 2021)

revision: learn '--no-kept-objects'

Signed-off-by: Taylor Blau
Reviewed-by: Jeff King

A future caller will want to be able to perform a reachability traversal which terminates when visiting an object found in a kept pack.
The closest existing option is '--honor-pack-keep', but this isn't quite what we want.
Instead of halting the traversal midway through, a full traversal is always performed, and the results are only trimmed afterwords.

Besides needing to introduce a new flag (since culling results post-facto can be different than halting the traversal as it's happening), there is an additional wrinkle handling the distinction in-core and on-disk kept packs.
That is: what kinds of kept pack should stop the traversal?

Introduce '--no-kept-objects[=<on-disk|in-core>]' to specify which kinds of kept packs, if any, should stop a traversal.
This can be useful for callers that want to perform a reachability analysis, but want to leave certain packs alone (for e.g., when doing a geometric repack that has some "large" packs which are kept in-core that it wants to leave alone).

Note: This is an "internal-use" option only, but interesting to know about, to experiment in your case.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250