git 2.45.1 made git fsck warn if the repository contains a symlink to the
git directory.

[[forum/Strange_symlinkPointsToGitDir_error]]

<https://fosstodon.org/@nobodyinperson/112478702707149836>

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?

> [[fixed|done]] in git --[[Joey]] 

----

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

Of course, that would not help when the bare repo is not git-annex
initialized.

If a git-annex repo is checked out on Windows and has a longer symlink,
this will cause fsck to complain about it, even though git-annex will of
course use an adjusted unlocked branch and so the symlink won't actually be
followed. That seems like a good reason to set these configs. OTOH, there's
no benefit in doing it on Linux, unless some other OS has a longer
`PATH_MAX` than 4096 (Hurd?)