NAME
git-annex config - configuration stored in git-annex branch
SYNOPSIS
git annex config --set name value
git annex config --get name
git annex config --unset name
git annex config --show-origin name
DESCRIPTION
Set or get configuration settings stored in the git-annex branch.
Unlike git config settings, these settings can be seen
in all clones of the repository, once they have gotten their
git-annex branches in sync.
These settings can be overridden on a per-repository basis using
git config.
git-annex does not check the git-annex branch for all the git config
settings that affect it (which are listed on the git-annex man page
CONFIGURATION section). Only a few make sense to be able to set such
that all clones of a repository see the setting, and so git-annex only
looks for these.
SUPPORTED SETTINGS
annex.numcopiesTells git-annex how many copies it should preserve of files, over all repositories. The default is 1.
When git-annex is asked to drop a file, it first verifies that the number of copies can be satisfied among all the other repositories that have a copy of the file.
In unusual situations, involving special remotes that do not support locking, and concurrent drops of the same content from multiple repositories, git-annex may violate the numcopies setting. It still guarantees at least 1 copy is preserved. This can be configured by setting annex.mincopies.
This is the same setting that the git-annex-numcopies(1) command configures. It can be overridden on a per-file basis by the annex.numcopies setting in
.gitattributesfiles.annex.mincopiesTells git-annex how many copies it is required to preserve of files, over all repositories. The default is 1.
This supplements the annex.numcopies setting. In unusual situations, involving special remotes that do not support locking, and concurrent drops of the same content from multiple repositories, git-annex may violate the numcopies setting. In these unusual situations, git-annex ensures that the number of copies never goes below mincopies.
It is a good idea to not only rely on only setting mincopies. Set numcopies as well, to a larger number, and keep mincopies at the bare minimum you're comfortable with. Setting mincopies to a large number, rather than setting numcopies will in some cases prevent droping content in entirely safe situations.
This is the same setting that the git-annex-mincopies(1) command configures. It can be overridden on a per-file basis by the annex.mincopies setting in
.gitattributesfiles.annex.largefilesUsed to configure which files are large enough to be added to the annex. It is an expression that matches the large files, eg "
include=*.mp3 or largerthan(500kb)". See git-annex-matching-expression(1) for details on the syntax.This configures the behavior of both git-annex and git when adding files to the repository. By default,
git-annex addadds all files to the annex (except dotfiles and files in dotdirs), andgit addadds files to git (unless they were added to the annex previously). When annex.largefiles is configured, bothgit annex addandgit addwill add matching large files to the annex, and the other files to git.Other git-annex commands also honor annex.largefiles, including
git annex import,git annex addurl,git annex importfeed,git-annex assist, and thegit-annex assistant.This sets a default, which can be overridden by annex.largefiles attributes in
.gitattributesfiles, or bygit config.annex.dotfilesNormally, dotfiles and files inside dotdirs are assumed to be configuration files like .gitignore, whose content should always be part of the git repository, so they will not be added to the annex. Setting annex.dotfiles to true makes these files be added to the annex the same as any other file.
This sets a default, which can be overridden by annex.dotfiles in
git config.annex.addunlockedCommands like
git-annex adddefault to adding files to the repository in locked form. This can make them add the files in unlocked form, the same as if git-annex-unlock(1) were run on the files.This can be set to "true" to add everything unlocked, or it can be a more complicated expression that matches files by name, size, or content. See git-annex-matching-expression(1) for details.
This sets a default, which can be overridden by annex.addunlocked in
git config.annex.autocommitSet to false to prevent the
git-annex assistant,git-annex assistandgit-annex syncfrom automatically committing changes to files in the repository.This sets a default, which can be overridden by annex.autocommit in
git config.annex.resolvemergeSet to false to prevent merge conflicts in the checked out branch being automatically resolved by the
git-annex assitant,git-annex sync,git-annex pull,`git-annex merge, and thegit-annex post-receivehook.This sets a default, which can be overridden by annex.resolvemerge in
git config.annex.synccontentSet to true to make
git-annex syncdefault to transferring annexed content.Set to false to prevent
git-annex pullandgit-annexpush from transferring annexed content.This sets a default, which can be overridden by annex.synccontent in
git config.annex.synconlyannexSet to true to make
git-annex sync,git-annex pullandgit-annex pushdefault to only operate on the git-annex branch and annexed content.This sets a default, which can be overridden by annex.synconlyannex in
git config.annex.securehashesonlySet to true to indicate that the repository should only use cryptographically secure hashes (SHA2, SHA3) and not insecure hashes (MD5, SHA1) for content.
When this is set, the contents of files using cryptographically insecure hashes will not be allowed to be added to the repository.
Also,
git-annex fsckwill complain about any files present in the repository that use insecure hashes.Note that this is only read from the git-annex branch by
git annex init, and is copied to the corresponding git config setting. So, changes to the value in the git-annex branch won't affect a repository once it has been initialized.
OPTIONS
--set name valueSet a value.
--get nameGet a value.
--unsetUnset a value.
--show-origin nameExplain where the value is configured, whether in the git-annex branch, or in a
git configfile, or.gitattributesfile. When a value is configured in multiple places, displays the place and the value that will be used.Note that the parameter can be the name of one of the settings listed above, but also any other configuration setting supported by git-annex. For example, "annex.backend" cannot be set in the git-annex branch, but it can be set in
.gitattributesorgit configand this option can explain which setting will be used for it.--for-file fileCan be used in combination with
--show-originto specify what filename to check for in.gitattributes.Also the git-annex-common-options(1) can be used.
EXAMPLE
Suppose you want to prevent git annex sync from committing changes to files, so a manual git commit workflow is used in all clones of the repository. Then run:
git annex config --set annex.autocommit false
If you want to override that in a partiticular clone, just use git config in the clone:
git config annex.autocommit true
And to get back to the default behavior:
git annex config --unset annex.autocommit
SEE ALSO
git-annex(1)
git-config(1)
AUTHOR
Joey Hess id@joeyh.name
Warning: Automatically converted into a man page by mdwn2man. Edit with care.

I`m using version: 5.20151208 and there is no such command as git annex config. It is also not listed on git annex help
@davi, you are using an ancient version of git-annex, from before this command was added. Upgrade.
@contr-error nope, only the config settings listed on this man page can be set with
git-annex config. Those others can only be set ingit config.I'd like to set a few additional configurations so that all clones treat a special remote similarly.
Particularly I'd like to set the trustlevel and tracking-branch for an exporttree special remote so that any clone that enables this remote also have these configurations enabled. In particular this is justified for a certain remote of mine because it exports to a version controlled environment that I trust, so it would just be nice not to have to run
git config remote.name.annex-tracking-branchandgit annex trust name semitrustedfor every clone.Of course, are
git annex config --set remote.name.annex-trustlevel "semitrusted"andgit annex config --set remote.name.annex-tracking-branch "main"(called once) any easier than the above called multiple times? Maybe not, but it would be slightly less mental overhead to not do the above.Off hand can you imagine any caveats that would preclude adding these settings to the list of supported for this command? I agree that only some make sense for all clones to see rather than anything one can set in git config but of course that specification requires manual addition of config cases that do make sense. Maybe this is one of them.
Is there any option/configuration to disable the creation and use of "synced/*" branches on
git annex sync?I have a simple "centralised" setup where local clones push/pull from a single remote bare repository, so I don't see the benefit of using "synced/*" branches. They mostly just add noise in whichever git GUI I use.