response

doc/todo/annex.addunlocked_in_gitattributes/comment_7_d06e3412f07d98c784b420d82d2d8d49._comment

@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-08-01T16:10:31Z"
+ content="""
+Well, moving your annex.largefiles settings from gitattributes to `git-annex
+config` won't speed up queries for it, because the gitattribute overrides
+the `git-annex config` setting. And so git-annex still has to do the work
+of querying for the gitattribute anyway, even when it's not set. 
+
+In [[!commit 4acbb40112aa73dcde63841d8d8c04c433f6a806]] I benchmarked that 
+as making `git-annex add` 2% slower than it would be otherwise (excluding
+hashing). We will just have to live with that, unless the gitattribute
+can eventually somehow be deprecated.
+That is a good lesson about the risks of adding more gitattributes. 
+
+annex.backend is not currently configurable by `git-annex config`.
+It would be listed in its man page if it were.
+
+I'd support adding that, but annex.backend is currently the name of a
+single backend, so this would not allow setting the backend differently for
+different filenames. Which is something that gitattributes can do. So it
+would need annex.backend to be expanded, so it can specify different
+backends for different filenames or other properties. I don't know how that
+syntax would look; the syntax git-annex currently uses for annex.largefiles
+etc is not suitable here. It would certianly be an added complication.
+
+Also, it seems that the reasoning that made the annex.largefiles 
+gitattributes override `git-annex config` would also make sense for
+annex.backend, and if so there would be no performance benefit to moving
+it. I'm not sure what that reasoning was. Possibly that there
+might be cases where the desired value depends on the branch that's checked
+out.
+"""]]