mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'trackassociated'

Browse source
This commit is contained in:
Joey Hess 2021-05-25 11:43:52 -04:00
commit 483fc4dc6b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
22 changed files with 302 additions and 168 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/indeterminite_preferred_content_state_for_duplicated_file.mdwn
View file

@ -19,3 +19,5 @@ So, this seems solvable in v7 repositories, but not in v5.
Also, the associated files map may not be accurate at all times, so that's
a wrinkle to using it for this. Also, only unlocked files get into the
associated files map. --[[Joey]]
> [[fixed|done]] --[[Joey]]

9
doc/git-annex-matching-options.mdwn
View file

@ -134,16 +134,17 @@ in either of two repositories.
Matches files that the preferred content settings for the repository
make it want to get. Note that this will match even files that are
already present, unless limited with e.g., `--not --in .`
Note that this will not match anything when using --all or --unused.
* `--want-drop`
Matches files that the preferred content settings for the repository
make it want to drop. Note that this will match even files that have
already been dropped, unless limited with e.g., `--in .`
Note that this will not match anything when using --all or --unused.
Files that this matches will not necessarily be dropped by
`git-annex drop --auto`. This does not check that there are enough copies
to drop. Also the same content may be used by a file that is not wanted
to be dropped.
* `--accessedwithin=interval`

7
doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_4_2cb31617bb7003c5bf0e5def358da0e4._comment
View file

@ -9,7 +9,12 @@ If most of the files are locked, that would actually make the scan
somewhere around twice as slow as it currently is. So not a worthwhile
optimisation.
And I don't see much else there that could be optimised. Possibly the
Update: Now that the scan also scans for locked files to make the
associated files include information about them, the catKey optimisation
did make sense. Unfortunately, that does mean this scan got a little bit
slower still, since it has to use git ls-tree --long.
I don't see much else there that could be optimised. Possibly the
ls-tree parser could be made faster but it's already using attoparsec
so unlikely to be many gains.
"""]]