File: comment_4_9c7677838ad28d540a2a514d718f9f1d._comment

package info (click to toggle)
git-annex 10.20230126-3
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 69,344 kB
  • sloc: haskell: 74,654; javascript: 9,103; sh: 1,304; makefile: 203; perl: 136; ansic: 44
file content (13 lines) | stat: -rw-r--r-- 869 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
[[!comment format=mdwn
 username="AlbertZeyer"
 avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
 subject="comment 4"
 date="2021-01-04T12:04:04Z"
 content="""
That is the best solution with `find`? There is no reverse index? I made a separate forum entry for this question [here](https://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/), to discuss that a bit more separately.

Why exactly does `git annex sync` (or other ops) get slower on bigger repos? In principle it could be implemented in a way that it should not get slower (basically always avoiding any need to iterate through all objects, which should always be possible to avoid by having some indices for any operations which needs that).

Does it make sense to split up the repo, but share the Git Annex object files (shared `.git/annex/objects`)?

"""]]