I came into a situation where a worktree index contains an invalid object ID in an extension. This causes git gc to abort half-way: $ git gc Enumerating objects: 6, done. Counting objects: 100% (6/6), done. fatal: unable to read d3e1a3edd7d7851bbf811064090e03475d62fd44 fatal: failed to run repack However, fsck does not find any problem: $ git fsck Checking object directories: 100% (256/256), done. The problem is an invalid object ID that occurs in a worktree index. If I copy the index to the main worktree, fsck does find the culprit: $ cp .git/worktrees/wt/index .git/index $ git fsck Checking object directories: 100% (256/256), done. error: d3e1a3edd7d7851bbf811064090e03475d62fd44: invalid sha1 pointer in resolve-undo error: 4b40bf1072d6dfeebc09b11ee4d4f22ca2ce3109: invalid sha1 pointer in resolve-undo error: 5a494fd3a2182795e0723300ab1ac75c0797be5b: invalid sha1 pointer in resolve-undo and git gc fails in the same way as before (of course). I see three problems here: - git fsck should detect the problem (if it really is one) in the worktree index. It seems that it is just an index extension that is affected. Perhaps it should be just a warning, not an error. - If the objects mentioned in the index extension are precious, they should not have been garbage-collected in earlier rounds of git gc (which I certainly did at some point). - I can't git gc the repository now, which is particularly annoying when auto-gc is attempted after almost every git command. Of course, I know how to get out of the situation, but it took some time to identify the worktree index as the culprit. Not something that a beginner would be able to do easily. The repository I use for the above commands is attached. I hope vger doesn't strip it away. -- Hannes
Attachment:
git-bug-gc-w-worktree-index.tar.gz
Description: application/gzip
