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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 11, 2018 at 10:23:41AM -0400, Jeff King wrote:

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux