git-annex/doc/todo/addunlocked_config_setting.mdwn

Can the `annex.addunlocked` be extended to have the same syntax as `annex.largefiles`?  Also, can there be separate settings affecting `git add` and `git annex add`, e.g. `annex.git-add.addunlocked` and `annex.git-annex-add.addunlocked`, with both defaulting to the value of `annex.addunlocked` if not set?

Basically, I want a reliable way to prevent inadvertently adding files as annexed unlocked files.

Related: [[forum/lets_discuss_git_add_behavior]]

> [[done]] --[[Joey]]
added suggestion for more fine-grained config of when files are added as locked vs unlocked 2019-10-07 18:08:44 +00:00			Can the `annex.addunlocked` be extended to have the same syntax as `annex.largefiles`? Also, can there be separate settings affecting `git add` and `git annex add`, e.g. `annex.git-add.addunlocked` and `annex.git-annex-add.addunlocked`, with both defaulting to the value of `annex.addunlocked` if not set?

			`Basically, I want a reliable way to prevent inadvertently adding files as annexed unlocked files.`

			`Related: [[forum/lets_discuss_git_add_behavior]]`
annex.addunlocked expressions * annex.addunlocked can be set to an expression with the same format used by annex.largefiles, in case you want to default to unlocking some files but not others. * annex.addunlocked can be configured by git-annex config. Added a git-annex-matching-expression man page, broken out from tips/largefiles. A tricky consequence of this is that git-annex add --relaxed honors annex.addunlocked, but an expression might want to know the size or content of an url, which it's not going to download. I decided it was better not to fail, and just dummy up some plausible data in that case. Performance impact should be negligible. The global config is already loaded for annex.largefiles. The expression only has to be parsed once, and in the simple true/false case, it should not do any additional work matching it. 2019-12-20 19:01:34 +00:00
			`> [[done]] --[[Joey]]`