Should annex.gitaddtoannex and annex.addsmallfiles be git-annex-config settings, given that annex.largefiles, annex.dotfiles and annex.addunlocked already are?
Also, maybe make annex.supportunlocked a git-annex-config setting as well.
supportunlocked would definitely make sense; it can help protect against users accidentally checking in a file in the wrong mode even though it doesn't fit the repo's workflows.
The alternative to setting this across all repos using git-annex config, at least in my workflows, would be to set a git hook to reject pushes (to master or synced/master) that contain unlocked files, but that sounds way more complex.
supportunlocked would definitely make sense; it can help protect against users accidentally checking in a file in the wrong mode even though it doesn't fit the repo's workflows.
The alternative to setting this across all repos using git-annex config, at least in my workflows, would be to set a git hook to reject pushes (to master or synced/master) that contain unlocked files, but that sounds way more complex.
annex.supportunlocked is documented to be about avoiding extra work needed to support unlocked files, and not about preventing them from being added to a branch.
In general, I do not want to add global config settings for every single git config setting. So if your only rartionalle for adding global configs is that other global configs that are somewhat related exist, that is not a compelling reason to me.
Of course. Just the settings that reflect the nature of the repo data and the intended usage processes. E.g. I want to be able to enforce that a repo be locked-files-only. Or to set
maxextensionlengthbased on the fact that the repo stores.fastq.gzfiles.To me it seems more natural to have it prevent the addition of unlocked files, and be a global setting.
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.
I have opened a new todo, need a clear criteria for adding git-annex-config settings.
I am going to close this one, because I'm certianly not adding a bunch of configs listed here without that crieria.