From 82ec9e5a5b4e227802e2e1351752fc8f64cf1d70 Mon Sep 17 00:00:00 2001 From: nobodyinperson Date: Sat, 15 Jul 2023 17:04:38 +0000 Subject: [PATCH] Added a comment --- ...ment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment new file mode 100644 index 0000000000..8eeeeb694b --- /dev/null +++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="nobodyinperson" + avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5" + subject="comment 16" + date="2023-07-15T17:04:38Z" + content=""" +> My current thinking is that when a repository does not have a preferred content expression, a content sync could avoid adding content to it. + +Technically, that would make the default preferred content expression `present` instead of `include=*`, right? I'd like that. Less unwanted content after the initial clone when running `git annex assist` or `git annex sync --content`. Goes into the direction of [specifying the default preferred content expression](https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/). Users having freshly cloned a repo can then explicitly `get` files or set up their preferred content expression. + +Many annexed repos will be huge in size and rarely one will want *everything* from it initially. Also great for DataLad datasets. +"""]]