From f70ae767dc9e285913ecfd6afa71e298bede3f8c Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Wed, 1 May 2024 19:06:56 +0000 Subject: [PATCH] question about assessing size of keys in tagged commits --- ..._47__wanted_exp_for_tagged_commits__63___.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/forum/get_storage_needed__47__wanted_exp_for_tagged_commits__63___.mdwn diff --git a/doc/forum/get_storage_needed__47__wanted_exp_for_tagged_commits__63___.mdwn b/doc/forum/get_storage_needed__47__wanted_exp_for_tagged_commits__63___.mdwn new file mode 100644 index 0000000000..ace197eaef --- /dev/null +++ b/doc/forum/get_storage_needed__47__wanted_exp_for_tagged_commits__63___.mdwn @@ -0,0 +1,15 @@ +I would like to retain a copy of keys which are referenced in a tagged commit. + +- is there some easy way to figure out size of keys across all such tagged commits? `git-annex info` seems to report per each commit/tree separately. I need a total size. + (I will need to assess it over hundreds of repos) + +- ATM I do not think it is possible directly with [preferred-content expressions](https://git-annex.branchable.com/git-annex-preferred-content/). + Do you think it would be feasible to develop support for retaining content based on the properties of the commit? + + Or what other "workflow" would you recommend? e.g. I guess upon tagging I could add to all keys some metadata field (e.g. `released`, may be with value of tags where it was released) and then set preferred-content based on having that metadata field? + + +Target use-case -- backup remote for dandisets will soon seize to exist, need to figure out some backup strategy. For that want to first assess how much of data which was tagged (higher priority to keep) to retain. + +[[!meta author=yoh]] +[[!tag projects/dandi]]