git 2.45.1 made git fsck warn if the repository contains a symlink to the git directory. [[forum/Strange_symlinkPointsToGitDir_error]] While this has impacts such as pushing a git-annex repository to gitlab now failing, this todo is not concerned with that (because it's not something that can be fixed in git-annex). What git-annex can do is configure fsck to not display this warning in a git-annex repository and to allow fetch and receive to work even when `fetch.fsckObjects` and `receive.fsckObjects` are set. git config fsck.symlinkPointsToGitDir ignore git config receive.fsck.symlinkPointsToGitDir ignore git config fetch.fsck.symlinkPointsToGitDir ignore It would be easy for git-annex init and upgrade to do this, but depending on the magnitude of breakage, which has not yet been assessed, git-annex may have to immediately make sure that all repositories it's used in get these configs. Is it at all common to set `git config fetch.fsckObjects true` or `git config receive.fsckObjects` true? ---- There is also potential breakage from git fsck now warning about symlink targets that exceed `PATH_MAX`. On Windows, that is 260. A SHA512 key has a symlink target of at least length 306. And even shorter keys, when located in deep subdirectories, can have longer symlink targets than that. So pushing to a bare repo on Windows could fail, for example. It even seems likely this could affect pushing to Freebsd in some cases, since its `PATH_MAX` is 1024 to Linux's 4096. If git-annex wanted to also avoid this breakage, it could set: git config fsck.symlinkTargetLength ignore git config receive.fsck.symlinkTargetLength ignore git config fetch.fsck.symlinkTargetLength ignore ---- Also this version of git added checks for hooks created at clone time, which breaks git clone using git-remote-annex when the special remote contains a git-annex branch. This is similar to how it broke git-lfs and I'm sure this part of the breakage will be reverted.