From ebe6c12cc017cbff745f109f3debcadae9b9c5b5 Mon Sep 17 00:00:00 2001 From: AlbertZeyer Date: Mon, 4 Jan 2021 12:04:04 +0000 Subject: [PATCH] Added a comment --- ...ment_4_9c7677838ad28d540a2a514d718f9f1d._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment diff --git a/doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment b/doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment new file mode 100644 index 0000000000..b0836dd5d2 --- /dev/null +++ b/doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment @@ -0,0 +1,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`)? + +"""]]