git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Help with "fatal: unable to read ...." error during GC?

From
Jeff King <peff@peff.net>
Date
Aug 11, 2018, 14:25 UTC
Message-ID
<20180811142527.GB17605@sigill.intra.peff.net>
In-Reply-To
<20180811142341.GA17605@sigill.intra.peff.net>
On Sat, Aug 11, 2018 at 10:23:41AM -0400, Jeff King wrote:
Show 45 quoted lines
> > I do still have these warnings and no amount of git gc/git fsck/etc.
> > has reduced them in any way:
> > 
> > $ git gc
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> 
> I think these would go away via "reflog expire" (I'd have thought "git
> gc" would do so, though). I wonder if this is yet another tool that
> needs to be taught about worktree heads.
> 
> > I've run git gc --prune=all then git fsck reports only these dangling
> > commits:
> > 
> > dangling commit cef0678a5e0765506e3fac41286696fd37a9b1e9
> > dangling commit 1729195f021a1b95ea8ca10b9c32e76bf2257e67
> > dangling commit 08385b9731291607a8c6d4bf10272002d8f31e1f
> > dangling commit c4ddfb2139eeb5a3c132dbfc84cc6e27fdeb46d1
> > dangling commit 1df8ebcc1cd5f59dd224ce1f3ba39f24370cf4e7
> > 
> > (this is down from probably 50 or so "dangling ..." commits, blobs, and
> > trees before).
> 
> I'd also expect "--prune=all" to drop all dangling heads. But I think
> this is the worktree thing, again. The code in fsck starts it
> connectivity check with this:
> 
>           if (head_points_at && !is_null_oid(&head_oid))
>                   fsck_handle_ref("HEAD", &head_oid, 0, NULL);
>           for_each_rawref(fsck_handle_ref, NULL);
>           if (include_reflogs)
>                   for_each_reflog(fsck_handle_reflog, NULL);
> 
> but looking at the similar code in revision.c that has been upgraded to
> handle worktrees (e.g., add_reflogs_to_pending()), I think that is not
> going to look at worktree HEADs nor reflogs.
> 
> I'd hoped to give you a one-liner to try out, but I think it will
> require some refactoring.

Responding myself and adding Duy to the cc to increase visibility among worktree experts. :)

-Peff
Previous: Jeff KingNext: Duy Nguyen
Message 10 of 13 in “Help with "fatal: unable to read ...." error during GC?”
  1. Paul SmithAug 8, 2018
  2. Jeff KingAug 8, 2018
  3. Paul SmithAug 8, 2018
  4. Jeff KingAug 8, 2018
  5. Paul SmithAug 8, 2018
  6. Paul SmithAug 9, 2018
  7. Jeff KingAug 9, 2018
  8. Paul SmithAug 11, 2018
  9. Jeff KingAug 11, 2018
  10. Jeff KingAug 11, 2018
  11. Duy NguyenAug 11, 2018
  12. Jeff KingAug 11, 2018
  13. Duy NguyenAug 12, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.