2017-01-30 20:41:29 +00:00
|
|
|
# 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
|
|
|
|
|
|
|
|
# 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.
|
|
|
|
|
|
|
|
# SUPPORTED SETTINGS
|
|
|
|
|
|
|
|
git-annex does not check the git-annex branch for all settings.
|
|
|
|
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:
|
|
|
|
|
|
|
|
These settings can be overridden on a per-repository basis using
|
2017-02-03 17:40:14 +00:00
|
|
|
`git config`.
|
2017-01-30 20:41:29 +00:00
|
|
|
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
* `annex.largefiles`
|
|
|
|
|
|
|
|
Used to configure which files are large enough to be added to the annex.
|
|
|
|
It is an expression that matches the large files, eg
|
2019-12-20 19:01:34 +00:00
|
|
|
"include=*.mp3 or largerthan(500kb)".
|
|
|
|
See [[git-annex-matching-expression]](1) for details on the syntax.
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
|
|
|
|
This sets a default, which can be overridden by annex.largefiles
|
|
|
|
attributes in `.gitattributes` files, or by `git config`.
|
|
|
|
|
2019-12-20 19:01:34 +00:00
|
|
|
* `annex.addunlocked`
|
|
|
|
|
|
|
|
Commands like `git-annex add` default 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`.
|
|
|
|
|
2017-02-03 17:40:14 +00:00
|
|
|
* `annex.autocommit`
|
|
|
|
|
2019-09-18 16:34:40 +00:00
|
|
|
Set to false to prevent the `git-annex assistant` and `git-annex sync`
|
2017-02-03 17:40:14 +00:00
|
|
|
from automatically committing changes to files in the repository.
|
2017-01-30 20:41:29 +00:00
|
|
|
|
2017-06-01 16:46:36 +00:00
|
|
|
* `annex.resolvemerge`
|
|
|
|
|
2018-02-22 18:25:32 +00:00
|
|
|
Set to false to prevent merge conflicts in the checked out branch
|
2019-09-18 16:34:40 +00:00
|
|
|
being automatically resolved by the `git-annex assitant`,
|
|
|
|
`git-annex sync`, `git-annex merge`, and the `git-annex post-receive`
|
|
|
|
hook.
|
2017-06-01 16:46:36 +00:00
|
|
|
|
2017-02-03 18:31:17 +00:00
|
|
|
* `annex.synccontent`
|
|
|
|
|
|
|
|
Set to true to make git-annex sync default to syncing content.
|
|
|
|
|
2017-02-27 20:08:16 +00:00
|
|
|
* `annex.securehashesonly`
|
|
|
|
|
|
|
|
Set to true to indicate that the repository should only use
|
2019-09-18 16:34:40 +00:00
|
|
|
cryptographically secure hashes (SHA2, SHA3) and not insecure
|
|
|
|
hashes (MD5, SHA1) for content.
|
2017-02-27 20:08:16 +00:00
|
|
|
|
|
|
|
When this is set, the contents of files using cryptographically
|
|
|
|
insecure hashes will not be allowed to be added to the repository.
|
|
|
|
|
2019-09-18 16:34:40 +00:00
|
|
|
Also, `git-annex fsck` will complain about any files present in
|
2017-02-27 20:08:16 +00:00
|
|
|
the repository that use insecure hashes.
|
2019-09-18 16:34:40 +00:00
|
|
|
|
2017-02-27 20:08:16 +00:00
|
|
|
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.
|
|
|
|
|
2017-01-30 20:41:29 +00:00
|
|
|
# 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
|
|
|
|
|
2017-02-03 18:31:17 +00:00
|
|
|
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:
|
2017-01-30 20:41:29 +00:00
|
|
|
|
|
|
|
git annex config --unset annex.autocommit
|
|
|
|
|
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
[[git-annex]](1)
|
|
|
|
|
|
|
|
git-config(1)
|
|
|
|
|
|
|
|
[[git-annex-vicfg]](1)
|
|
|
|
|
|
|
|
# AUTHOR
|
|
|
|
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|