work around git "defense in depth" breakage with git clone checking for hooks

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.
This commit is contained in:
Joey Hess 2024-05-24 15:49:53 -04:00
parent 6ccd09298b
commit 04a256a0f8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 21 additions and 9 deletions

View file

@ -40,10 +40,3 @@ 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.