29e73f76ef
The former can be useful to make remotes that don't get fully synced with local changes, which comes up in a lot of situations. The latter was mostly added for symmetry, but could be useful (though less likely to be). Implementing `remote.<name>.annex-pull` was a bit tricky, as there's no one place where git-annex pulls/fetches from remotes. I audited all instances of "fetch" and "pull". A few cases were left not checking this config: * Git.Repair can try to pull missing refs from a remote, and if the local repo is corrupted, that seems a reasonable thing to do even though the config would normally prevent it. * Assistant.WebApp.Gpg and Remote.Gcrypt and Remote.Git do fetches as part of the setup process of a remote. The config would probably not be set then, and having the setup fail seems worse than honoring it if it is already set. I have not prevented all the code that does a "merge" from merging branches from remotes with remote.<name>.annex-pull=false. That could perhaps be done, but it would need a way to map from branch name to remote name, and the way refspecs work makes that hard to get really correct. So if the user fetches manually, the git-annex branch will get merged, for example. Anther way of looking at/justifying this is that the setting is called "annex-pull", not "annex-merge". This commit was supported by the NSF-funded DataLad project.
126 lines
4.1 KiB
Markdown
126 lines
4.1 KiB
Markdown
# NAME
|
|
|
|
git-annex sync - synchronize local repository with remotes
|
|
|
|
# SYNOPSIS
|
|
|
|
git annex sync `[remote ...]`
|
|
|
|
# DESCRIPTION
|
|
|
|
This command synchronizes the local repository with its remotes.
|
|
|
|
The sync process involves first committing any local changes to files
|
|
that have previously been added to the repository,
|
|
then fetching and merging the `synced/master` and the `git-annex` branch
|
|
from the remote repositories, and finally pushing the changes back to
|
|
those branches on the remote repositories. You can use standard git
|
|
commands to do each of those steps by hand, or if you don't want to
|
|
worry about the details, you can use sync.
|
|
|
|
The content of annexed objects is not synced by default, but the --content
|
|
option (see below) can make that also be synchronized.
|
|
|
|
Merge conflicts are automatically handled by sync. When two conflicting
|
|
versions of a file have been committed, both will be added to the tree,
|
|
under different filenames. For example, file "foo" would be replaced
|
|
with "foo.somekey" and "foo.otherkey".
|
|
|
|
Note that syncing with a remote will not update the remote's working
|
|
tree with changes made to the local repository. However, those changes
|
|
are pushed to the remote, so they can be merged into its working tree
|
|
by running "git annex sync" on the remote.
|
|
|
|
# OPTIONS
|
|
|
|
* `[remote]`
|
|
|
|
By default, all remotes are synced, except for remotes that have
|
|
`remote.<name>.annex-sync` set to false. By specifying the names
|
|
of remotes (or remote groups), you can control which ones to sync with.
|
|
|
|
* `--fast`
|
|
|
|
Only sync with the remotes with the lowest annex-cost value configured.
|
|
|
|
* `--commit`, `--no-commit`
|
|
|
|
A commit is done by default (unless annex.autocommit is set to false).
|
|
|
|
Use --no-commit to avoid committing local changes.
|
|
|
|
* `--message=msg`
|
|
|
|
Use this option to specify a commit message.
|
|
|
|
* `--pull`, `--no-pull`
|
|
|
|
By default, git pulls from remotes. Use --no-pull to disable all pulling.
|
|
|
|
When `remote.<name>.annex-pull` or `remote.<name>.annex-sync`
|
|
are set to false, pulling is disabled for those remotes, and using
|
|
`--pull` will not enable it.
|
|
|
|
* `--push`, `--no-push`
|
|
|
|
By default, git pushes changes to remotes.
|
|
Use --no-push to disable all pushing.
|
|
|
|
When `remote.<name>.annex-push` or `remote.<name>.annex-sync` are
|
|
set to false, or `remote.<name>.annex-readonly` is set to true,
|
|
pushing is disabled for those remotes, and using `--push` will not enable
|
|
it.
|
|
|
|
* `--content`, `--no-content`
|
|
|
|
Normally, syncing does not transfer the contents of annexed files.
|
|
The --content option causes the content of files in the work tree
|
|
to also be uploaded and downloaded as necessary.
|
|
|
|
The `annex.synccontent` configuration can be set to true to make content
|
|
be synced by default.
|
|
|
|
Normally this tries to get each annexed file in the work tree
|
|
that the local repository does not yet have, and then copies each
|
|
file in the work tree to every remote that it is syncing with.
|
|
This behavior can be overridden by configuring the preferred content
|
|
of a repository. See [[git-annex-preferred-content]](1).
|
|
|
|
* `--content-of=path` `-C path`
|
|
|
|
While --content operates on all annexed files in the work tree,
|
|
--content-of allows limiting the transferred files to ones in a given
|
|
location.
|
|
|
|
This option can be repeated multiple times with different paths.
|
|
|
|
* `--all`
|
|
|
|
This option, when combined with `--content`, makes all available versions
|
|
of all files be synced, when preferred content settings allow.
|
|
|
|
Note that preferred content settings that use `include=` or `exclude=`
|
|
will only match the version of files currently in the work tree, but not
|
|
past versions of files.
|
|
|
|
* `--jobs=N` `-JN`
|
|
|
|
Enables parallel syncing with up to the specified number of jobs
|
|
running at once. For example: `-J10`
|
|
|
|
When there are multiple git remotes, pushes will be made to them in
|
|
parallel. Pulls are not done in parallel because that tends to be
|
|
less efficient. When --content is synced, the files are processed
|
|
in parallel as well.
|
|
|
|
# SEE ALSO
|
|
|
|
[[git-annex]](1)
|
|
|
|
[[git-annex-preferred-content]](1)
|
|
|
|
# AUTHOR
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|