[PATCH 0/3] fsck index files from all worktrees
- From
Jeff King <peff@peff.net>
- Date
- Feb 24, 2023, 08:05 UTC
- Message-ID
- <Y/hv0MXAyBY3HEo9@coredump.intra.peff.net>
- In-Reply-To
- <c6246ed5-bffc-7af9-1540-4e2071eff5dc@kdbg.org>
On Sat, Feb 18, 2023 at 10:38:33AM +0100, Johannes Sixt wrote:
Show 5 quoted lines
> 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.
We do fsck the resolve-undo extension, but I think fsck just doesn't know anything about worktrees. That should be easy enough to fix. Patches below.
> - 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).
Correct, but the gc error you're getting indicates that we _are_ trying to treat them as included. I wonder if you ran git-gc long ago with an older version of Git, and this breakage was waiting to surface. AFAICT this was all fixed by 8a044c7f1d (Merge branch 'nd/prune-in-worktree', 2017-09-19).
Show 5 quoted lines
> - 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.
I think in general that "oops, there's something corrupt" can be hard to get out of, just because there are so many possibilities. But if we can at least report the nature of the problem and the offending filename via git-fsck, that would help with pointing people in the right direction.
> The repository I use for the above commands is attached. I hope vger > doesn't strip it away.
Thanks, it was nice to have a test case. I ended up writing a separate test with a missing blob, just because that's simpler to do. It looks like we don't test fsck_resolve_undo() or fsck_cache_tree() at all. That might be a nice addition, but I punted for now to stay focused on the worktree aspects.
[1/3]: fsck: factor out index fsck [2/3]: fsck: check index files in all worktrees [3/3]: fsck: mention file path for index errors
builtin/fsck.c | 93 ++++++++++++++++++++++++++++++++----------------- t/t1450-fsck.sh | 30 ++++++++++++++++ 2 files changed, 92 insertions(+), 31 deletions(-)
-Peff