todo/annex.addunlocked in gitattributesgit-annexhttp://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/git-annexikiwiki2022-08-01T16:45:44Zcomment 1http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_1_1d21cde3d21a9b5bb129b17b9e0fc95d/yarikoptic2022-02-18T20:18:04Z2022-02-18T20:18:04Z
Dear Joey, could you please elaborate on what "other means" it was accomplished through? we are on the expedition ATM to discover.
comment 2http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_2_38f248f7596646dfc11248f0149c0beb/yarikoptic2022-02-18T21:56:19Z2022-02-18T21:56:19Z
I guess it is the fact that this particular config variable is also supported by <code>git annex config</code> so could be set persistently (across clones) this way.
comment 3http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_3_270c5156c8adce0aff86eda5f2746703/joey2022-02-21T19:46:26Z2022-02-21T19:40:50Z
<p>Yes, annex.addunlocked with a matching expression was
implemented in 2019 and accomplishes the same thing
as this would have, without the problems of using git attributes.</p>
comment 4http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_4_d87e08ccdec98867dd52b629e6fad330/yarikoptic2022-02-21T21:53:03Z2022-02-21T21:53:03Z
<p>just it is getting a bit "confusing" to use <code>.gitattributes</code> for some types of annotations (e.g., <code>largefiles</code>) for files patterns and then <code>git annex config</code> for others. Ideally there should either be a singular or equivalently expressive (not complimentary) multiple ways.</p>
<blockquote><p>without the problems of using git attributes</p></blockquote>
<p>could you please remind (or point to prior composed list) of those? I personally just keep forgetting which one (first or last match) applies <img src="http://git-annex.branchable.com/smileys/smile4.png" alt=";)" /></p>
comment 5http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_5_be25f3b3c2279eb3fd3ef69c4d1cb52d/joey2022-02-25T17:32:40Z2022-02-25T17:28:20Z
<p>git-annex config does work for both largefiles and addunlocked.</p>
<p>gitattributes does not allow setting an attribute containing a space
and so complex expressions, which either of these can have, become very
annoying to shoehorn in. gitattributes also adds a round-trip overhead
to query it for every file.</p>
question about backendhttp://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_6_f672dee4c1712e0d20dd820999598d87/yarikoptic2022-02-28T22:42:33Z2022-02-28T22:42:33Z
<p>ATM we rely on .gitattributes to set default (to DataLad datasets) backend to be MD5E, so every dataset then is guaranteed to have <code>.gitattributes</code>. We also rely in many configurations on setting <code>largefiles</code> for different extensions within <code>.gitattributes</code>. I think this is two primary target use cases. You say that having <code>.gitattributes</code> slows down <code>git</code> (and <code>git-annex</code>) operations -- so would you recommend to switch to specifying those (backend, largefiles) via <code>git annex config</code> instead?</p>
<p>In <a href="https://github.com/datalad/datalad/issues/5383">datalad/issues/5383 (Stop using .gitattributes for annex.largefiles config )</a> note was that default backend cannot be specified via <code>git-annex config</code> -- is that still the case?</p>
comment 7http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_7_d06e3412f07d98c784b420d82d2d8d49/joey2022-08-01T16:36:51Z2022-08-01T16:10:31Z
<p>Well, moving your annex.largefiles settings from gitattributes to <code>git-annex
config</code> won't speed up queries for it, because the gitattribute overrides
the <code>git-annex config</code> setting. And so git-annex still has to do the work
of querying for the gitattribute anyway, even when it's not set.</p>
<p>In <a href="http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=4acbb40112aa73dcde63841d8d8c04c433f6a806">4acbb40112aa73dcde63841d8d8c04c433f6a806</a> I benchmarked that
as making <code>git-annex add</code> 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.</p>
<p>annex.backend is not currently configurable by <code>git-annex config</code>.
It would be listed in its man page if it were.</p>
<p>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.</p>
<p>Also, it seems that the reasoning that made the annex.largefiles
gitattributes override <code>git-annex config</code> 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.</p>
comment 8http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_8_73a402df13f30b279dfd2914adec5f35/joey2022-08-01T16:38:42Z2022-08-01T16:37:20Z
<p>I would support adding annex.backend to <code>git-annex config</code> using the
current simple value though. There is benefit to doing it for consistencty,
surely. If a more complicated syntax is needed someone
can still use gitattributes or git-annex could be changed later.</p>
<p>Please open a new todo if this would be useful to you..</p>
comment 9http://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/comment_9_02866c504617c2914eff01d3529d5cc7/joey2022-08-01T16:45:44Z2022-08-01T16:39:40Z
<p>I also think that the thinking in this comment is worth considering:
<a href="https://github.com/datalad/datalad/issues/5383#issuecomment-770108778">https://github.com/datalad/datalad/issues/5383#issuecomment-770108778</a></p>
<p>Those are valid reasons to prefer to be able to set things like this
in gitattributes rather than the global config. Those kinds of
considerations are why the global config always has a local way to override
it. Sometimes that is necessarily .git/config, not .gitattributes though.</p>