Snapshots read git attributes from the right place in linked worktrees, and explain symlinked .gitattributes failures.
What's wrong with this entry?
Snapshotting now reads .git/info/attributes from the repository's shared git directory rather than the per-worktree one, which is the right location when you work in a linked worktree. When filter attributes cannot be read from a commit because the installed git follows a committed symlinked .gitattributes on disk, it now stops with an explicit message telling you to update git.
- The message names the cause and the remedy: git older than 2.32, or a version this build cannot read.
- The attribute read is isolated: the
check-attrcall runs with a per-run object directory and with alternate object directories emptied, so it cannot disturb the repository. - Any blob rewritten during the read is re-staged with
update-index --cacheinfo.
a committed .gitattributes is a symbolic link, which the installed git (older than 2.32, or of a version this build cannot read) follows on disk: update git, then retry
Strings lifted out of the shipped bundle, so the claim above can be checked against them.