From 0c1df95dd7f94c7cde930a60b6a59c4e1ccb7b0d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 25 Jun 2021 14:15:14 -0400 Subject: [PATCH] comment --- ...t_1_3e7c731037b8ce7148a6a597783d2ba3._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment diff --git a/doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment b/doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment new file mode 100644 index 0000000000..63f38f7758 --- /dev/null +++ b/doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2021-06-25T17:56:02Z" + content=""" +I'm not super enthused by this idea. The git-check-attr interface would +make it hard to avoid using one process per use of the option. +Checking attributes can be slow. Attributes are limited in what +they can contain. Some places where git-annex uses gitattributes I have +ended up regretting it. A compelling use case would be good. + +Might also be possible to support this in preferred content. Although it +looks a bit hard to do, because it would need to start up a git-check-attr +process for each different attribute used, while parsing the preferred content +expression. +"""]]