comment

doc/todo/additional_git-annex-config_settings__63__/comment_6_4ec0261f3b8bc6d2492fa3dabb0121e5._comment

@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-12T15:42:52Z"
+ content="""
+Almost anything can be argued to reflect the nature of some repo in some way.
+That's not a useful criteria.
+
+And the same could be argued about many git configs, and of course they
+cannot be set globally, and noone is bothered much by this, because we can
+all arrange for git configs to be set after cloning a repo.
+
+I don't know what the right criteria is, but I do know I don't want to
+force users to have to worry about overriding every possible config locally
+because it's been set globally. git-annex should not behave in a near infinity
+of different ways in clones of different repos, because that would make its
+starting behavior impossible to understand.
+
+So the more there are requests for more global configs, the more it seems
+like adding any global configs, without a strong criteria, is not a good
+idea.
+
+Some global configs that do make sense are numcopies and required copies
+settings, because those values need to be coordinated globally to make sure
+enough copies are preserved. Similarly, preferred content because one
+repo needs to know what is preferred content of another repo. And I think
+annex.securehashesonly makes sense as a global, to avoid adding files
+with insecure hashes that would then not be accessible in repos with
+that config set. annex.largefiles mostly makes sense because .gitattributes
+has a whitespace problem which it avoids, and it's similar to using
+.gitattributes (although not identical). It feels on the edge.
+
+annex.synccontent etc are explicitly about changing the default behavior
+of a command. At the moment I feel like they were a bad idea.
+"""]]