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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2020-12-17 16:17:58 +00:00
|
|
|
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
|
|
|
|
|
|
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`
|
|
|
|
|
|
2022-03-29 19:03:57 +00:00
|
|
|
Used 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.
|
git-annex assist
assist: New command, which is the same as git-annex sync but with
new files added and content transferred by default.
(Also this fixes another reversion in git-annex sync,
--commit --no-commit, and --message were not enabled, oops.)
See added comment for why git-annex assist does commit staged
changes elsewhere in the work tree, but only adds files under
the cwd.
Note that it does not support --no-commit, --no-push, --no-pull
like sync does. My thinking is, why should it? If you want that
level of control, use git commit, git annex push, git annex pull.
Sync only got those options because pull and push were not split
out.
Sponsored-by: k0ld on Patreon
2023-05-18 18:37:29 +00:00
|
|
|
|
|
|
|
|
This configures the behavior of both git-annex and git when adding
|
|
|
|
|
files to the repository. By default, `git-annex add` adds all files
|
|
|
|
|
to the annex (except dotfiles), and `git add` adds files to git
|
|
|
|
|
(unless they were added to the annex previously).
|
|
|
|
|
When annex.largefiles is configured, both
|
|
|
|
|
`git annex add` and `git add` will 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 the `git-annex assistant`.
|
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
|
|
|
|
2022-03-29 19:03:57 +00:00
|
|
|
This sets a default, which can be overridden by annex.largefiles
|
|
|
|
|
attributes in `.gitattributes` files, or by `git config`.
|
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
|
|
|
|
2019-12-26 20:24:40 +00:00
|
|
|
* `annex.dotfiles`
|
|
|
|
|
|
2022-03-29 19:03:57 +00:00
|
|
|
Normally, dotfiles are assumed to be 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 dotfiles be added to the annex the same as any other file.
|
2019-12-26 20:24:40 +00:00
|
|
|
|
2022-03-29 19:03:57 +00:00
|
|
|
This sets a default, which can be overridden by annex.dotfiles
|
|
|
|
|
in `git config`.
|
2019-12-26 20:24:40 +00:00
|
|
|
|
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`
|
|
|
|
|
|
git-annex assist
assist: New command, which is the same as git-annex sync but with
new files added and content transferred by default.
(Also this fixes another reversion in git-annex sync,
--commit --no-commit, and --message were not enabled, oops.)
See added comment for why git-annex assist does commit staged
changes elsewhere in the work tree, but only adds files under
the cwd.
Note that it does not support --no-commit, --no-push, --no-pull
like sync does. My thinking is, why should it? If you want that
level of control, use git commit, git annex push, git annex pull.
Sync only got those options because pull and push were not split
out.
Sponsored-by: k0ld on Patreon
2023-05-18 18:37:29 +00:00
|
|
|
Set to false to prevent the `git-annex assistant`, `git-annex assist`
|
|
|
|
|
and `git-annex sync` from automatically committing changes to files
|
|
|
|
|
in the repository.
|
2022-03-29 19:03:57 +00:00
|
|
|
|
|
|
|
|
This sets a default, which can be overridden by annex.autocommit
|
|
|
|
|
in `git config`.
|
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 pull and push
Split out two new commands, git-annex pull and git-annex push. Those plus a
git commit are equivilant to git-annex sync.
In a sense, git-annex sync conflates 3 things, and it would have been
better to have push and pull from the beginning and not sync. Although
note that git-annex sync --content is faster than a pull followed by a
push, because it only has to walk the tree once, look at preferred
content once, etc. So there is some value in git-annex sync in speed, as
well as user convenience.
And it would be hard to split out pull and push from sync, as far as the
implementaton goes. The implementation inside sync was easy, just adjust
SyncOptions so it does the right thing.
Note that the new commands default to syncing content, unless
annex.synccontent is explicitly set to false. I'd like sync to also do
that, but that's a hard transition to make. As a start to that
transition, I added a note to git-annex-sync.mdwn that it may start to
do so in a future version of git-annex. But a real transition would
necessarily involve displaying warnings when sync is used without
--content, and time.
Sponsored-by: Kevin Mueller on Patreon
2023-05-16 20:37:30 +00:00
|
|
|
`git-annex sync`, `git-annex pull`, ``git-annex merge`,
|
|
|
|
|
and the `git-annex post-receive` hook.
|
2022-03-29 19:03:57 +00:00
|
|
|
|
|
|
|
|
This sets a default, which can be overridden by annex.resolvemerge
|
|
|
|
|
in `git config`.
|
2017-06-01 16:46:36 +00:00
|
|
|
|
2017-02-03 18:31:17 +00:00
|
|
|
* `annex.synccontent`
|
|
|
|
|
|
git-annex pull and push
Split out two new commands, git-annex pull and git-annex push. Those plus a
git commit are equivilant to git-annex sync.
In a sense, git-annex sync conflates 3 things, and it would have been
better to have push and pull from the beginning and not sync. Although
note that git-annex sync --content is faster than a pull followed by a
push, because it only has to walk the tree once, look at preferred
content once, etc. So there is some value in git-annex sync in speed, as
well as user convenience.
And it would be hard to split out pull and push from sync, as far as the
implementaton goes. The implementation inside sync was easy, just adjust
SyncOptions so it does the right thing.
Note that the new commands default to syncing content, unless
annex.synccontent is explicitly set to false. I'd like sync to also do
that, but that's a hard transition to make. As a start to that
transition, I added a note to git-annex-sync.mdwn that it may start to
do so in a future version of git-annex. But a real transition would
necessarily involve displaying warnings when sync is used without
--content, and time.
Sponsored-by: Kevin Mueller on Patreon
2023-05-16 20:37:30 +00:00
|
|
|
Set to true to make `git-annex sync` default to transferring
|
|
|
|
|
annexed content.
|
|
|
|
|
|
|
|
|
|
Set to false to prevent `git-annex pull` and `git-annex` push from
|
|
|
|
|
transferring annexed content.
|
2022-03-29 19:03:57 +00:00
|
|
|
|
|
|
|
|
This sets a default, which can be overridden by annex.synccontent
|
|
|
|
|
in `git config`.
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
|
|
|
|
|
* `annex.synconlyannex`
|
|
|
|
|
|
git-annex pull and push
Split out two new commands, git-annex pull and git-annex push. Those plus a
git commit are equivilant to git-annex sync.
In a sense, git-annex sync conflates 3 things, and it would have been
better to have push and pull from the beginning and not sync. Although
note that git-annex sync --content is faster than a pull followed by a
push, because it only has to walk the tree once, look at preferred
content once, etc. So there is some value in git-annex sync in speed, as
well as user convenience.
And it would be hard to split out pull and push from sync, as far as the
implementaton goes. The implementation inside sync was easy, just adjust
SyncOptions so it does the right thing.
Note that the new commands default to syncing content, unless
annex.synccontent is explicitly set to false. I'd like sync to also do
that, but that's a hard transition to make. As a start to that
transition, I added a note to git-annex-sync.mdwn that it may start to
do so in a future version of git-annex. But a real transition would
necessarily involve displaying warnings when sync is used without
--content, and time.
Sponsored-by: Kevin Mueller on Patreon
2023-05-16 20:37:30 +00:00
|
|
|
Set to true to make `git-annex sync`, `git-annex pull` and `git-annex
|
|
|
|
|
push` default to only operate on the git-annex branch and annexed content.
|
2022-03-29 19:03:57 +00:00
|
|
|
|
|
|
|
|
This sets a default, which can be overridden by annex.synconlyannex
|
|
|
|
|
in `git config`.
|
2017-02-03 18:31:17 +00:00
|
|
|
|
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.
|
|
|
|
|
|
2021-05-10 19:00:13 +00:00
|
|
|
# OPTIONS
|
|
|
|
|
|
|
|
|
|
* `--set name value`
|
|
|
|
|
|
|
|
|
|
Set a value.
|
|
|
|
|
|
|
|
|
|
* `--get name`
|
|
|
|
|
|
|
|
|
|
Get a value.
|
|
|
|
|
|
|
|
|
|
* `--unset`
|
|
|
|
|
|
|
|
|
|
Unset a value.
|
|
|
|
|
|
|
|
|
|
* Also the [[git-annex-common-options]](1) can be used.
|
|
|
|
|
|
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.
|