47084b8a1d
This has tradeoffs, but is generally a win, and users who it causes git add to slow down unacceptably for can just disable it again. It needed to happen in an upgrade, since there are git-annex versions that do not support it, and using such an old version with a v8 repository with filter.annex.process set will cause bad behavior. By enabling it in v9, it's guaranteed that any git-annex version that can use the repository does support it. Although, this is not a perfect protection against problems, since an old git-annex version, if it's used with a v9 repository, will cause git add to try to run git-annex filter-process, which will fail. But at least, the user is unlikely to have an old git-annex in path if they are using a v9 repository, since it won't work in that repository. Sponsored-by: Dartmouth College's Datalad project
22 lines
825 B
Markdown
22 lines
825 B
Markdown
This is a todo for collecting changes that could lead to a v9 repository
|
|
version.
|
|
|
|
Currently, there does not seem to be enough reason to warrant one, but that
|
|
could change and if it does, these things could be included.
|
|
|
|
* Change locking of annexed files to use a separate lock file
|
|
rather than posix locking the file itself.
|
|
|
|
This would let write bits be removed from the file when
|
|
core.sharedRepository is set. See <https://git-annex.branchable.com/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/>
|
|
|
|
Note that windows already uses a separate lock file.
|
|
|
|
This is being implemented in git branch `v9-locking`.
|
|
|
|
* Possibly enable `git-annex filter-process` by default. If the tradeoffs
|
|
seem worth it.
|
|
|
|
May want to implement [[incremental_hashing_for_add]] first.
|
|
|
|
[[done]] --[[Joey]]
|