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:
parent
6ccd09298b
commit
04a256a0f8
3 changed files with 21 additions and 9 deletions
|
@ -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.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue