From 0f9eafc157af529c54f2b122882e5cf5cf18ed7d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 24 Sep 2018 11:50:40 -0400 Subject: [PATCH] comment --- ..._c17fdd288b4912455f48d95b0bdc2390._comment | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment diff --git a/doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment b/doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment new file mode 100644 index 0000000000..d298c06d43 --- /dev/null +++ b/doc/todo/support_longer_file_extensions/comment_1_c17fdd288b4912455f48d95b0bdc2390._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2018-09-24T15:45:07Z" + content=""" +What you're suggesting with the full filenames is basically on the same +level of complexity as direct mode or v6's unlocked files, which both avoid +symlinks and so avoid problems with the rare program that looks at the +extension of a symlink target, instead of the extension of the symlink. + +Doing something to allow longer extensions is maybe worth talking more +about though. I am not very keen on adding a parameter to the backend name. + +The way git-annex picks extensions doesn't need to be stable across all +versions of git-annex, because it's only done when initially adding a file, +and then the key, with whatever extension, is added as-is and git-annex +does not care about the extension thereafter. So, a +configuration setting to pick the extension length, or something like that, +would be possible to add. +"""]]