"Kristoffer Haugsbakk" <code@xxxxxxxxxxxxxxx> writes: > On Sat, May 31, 2025, at 05:39, shejialuo wrote: >> It is reported that "git refs verify" would fail when encountering >> worktrees created on Git v2.43.0 or older versions. These versions > > Nit: maybe > > "git refs verify" doesn't work if there are worktrees created on Git > v2.43.0 ... Yeah, "It is reported that" was somewhat odd introduction. >> don't automatically create the "refs" directory, causing the error: >> >> error: cannot open directory .git/worktrees/<worktree name>/refs: >> No such file or directory The original of this part already reads quite well, I think. >> Since 8f4c00de95 (builtin/worktree: create refdb via ref backend, >> 2024-01-08), we automatically create the "refs" directory for new >> worktrees. However, the fsck code incorrectly assumes all linked >> worktrees have this directory, thus introducing compatibility issue. > > Thanks for finding that commit. Yup. And that one is v2.44.0-rc0~58^2, and that is where "v2.43" in the above description comes from. > At this point in the message it seems like the fsck code never worked > with these old linked worktrees. But `git refs verify` used to work > with them until 7c78d819e6a (ref: support multiple worktrees check for > refs, 2024-11-20) which was part of v2.48.0. So I think it’s worth > mentioning that commit as well. Good suggestion. > Like I said in the first email the only minor regression in this release > cycle is that git-fsck(1) reports these errors on stderr because the > default `--reference`. This was how I spotted the issue on rc0. But I > neglected to mention that the commit that introduced `--references` > (default) for git-fsck(1) is v2.48.0-rc1-49-gc1cf918d3ad (builtin/fsck: > add `git refs verify` child process, 2025-02-28).[1] Thanks for a careful analysis. The "fix" is rather obvious, so let's see if we can come up with the final wording of the commit log message and merge it down in time ;-).
