From 1d9bad51d2c369bff870b1977f5327e76d8eb561 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 21 May 2021 13:50:26 -0400 Subject: [PATCH] plan for these --- ..._28e601e7bf6a55402d9c26798d88e459._comment | 47 +++++++++++++++++++ ..._5fb82eb18c6d935ac07ec9220d9037c0._comment | 10 ++++ 2 files changed, 57 insertions(+) create mode 100644 doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_8_28e601e7bf6a55402d9c26798d88e459._comment create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment diff --git a/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_8_28e601e7bf6a55402d9c26798d88e459._comment b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_8_28e601e7bf6a55402d9c26798d88e459._comment new file mode 100644 index 0000000000..dd7a7ec9f9 --- /dev/null +++ b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_8_28e601e7bf6a55402d9c26798d88e459._comment @@ -0,0 +1,47 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 8""" + date="2021-05-21T17:05:48Z" + content=""" +I think Ilya is on the right track with recording the last treeish scanned +for keys and diffing to the current treeish. This seems worth implementing. + +So, plan: + +* When dropping a file, after checking that it's not preferred content, + or when needed for +* When the stat of the index differs from the last recorded stat +* Generate a tree from the index with `git write-tree`, and when it + differs from the last recorded such tree +* `git diff-index --cached` with the last recorded tree, parse and cat + the links, and update the keys database associated files with the keys + it found. Note that it can also remove associated files when files get + deleted, which is currently not done. +* Then, look up in the keys database the associated files of the key, and + also check if the preferred content matches any of those other files. + So in the example above, it won't drop `archive/bar` because `foo` is + still preferred content. + +This would not notice if a file was moved or deleted but that was not +staged in the index yet. I think that's ok -- If the file is moved and not +staged yet, it's not been added to git, so it's acceptable for git-annex to +not try to keep content around for it (git-annex unused would not either +in similar situations). If the file is deleted, git-annex might not drop +the content yet because it's still present in the index, but the same +happens if you delete a file and then `git annex drop .`, because it skips +over the deleted file whether or not it's staged in the index. + +It seems sufficient to only do this when dropping a file, not in other +commands. That means the associated files database remains incomplete +for other commands, not including recent changes to locked files. +Since this is only a problem for dropping, and the associated files +database is not needed for locked files generally, that seems ok, although +it would certianly be a nice simplification if the database was always +kept up-to-date. Since the update could be a pretty expensive operation, +probably best to keep it for the drops that really need it. + +Note that the `git write-tree` would mean that using git-annex could +create these tree objects, which never end up getting used. gc would +eventually delete them, but there might be a situation where doing this +a lot bloats the repo. +"""]] diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment new file mode 100644 index 0000000000..b2b2ff83a0 --- /dev/null +++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2021-05-21T17:29:09Z" + content=""" +I have a plan over in [[bugs/indeterminite_preferred_content_state_for_duplicated_file]] +and will be working on it over there. + +Linked worktrees seems out of scope for this though. +"""]]