04a256a0f8
This git bug also broke git-lfs, and I am confident it will be reverted in the next release. For now, cloning from an annex:: url wastes some bandwidth on the next pull by not caching bundles locally. If git doesn't fix this in the next version, I'd be tempted to rethink whether bundle objects need to be cached locally. It would be possible to instead remember which bundles have been seen and their heads, and respond to the list command with the heads, and avoid unbundling them agian in fetch. This might even be a useful performance improvement in the latter case. It would be quite a complication to a currently simple implementation though.
42 lines
1.7 KiB
Markdown
42 lines
1.7 KiB
Markdown
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?
|
|
|
|
----
|
|
|
|
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
|