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 current branch 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.
When using git-annex, often remotes are not bare repositories, because it's helpful to add remotes for nearby machines that you want to access the same annexed content. Syncing with a non-bare remote will not normally update the remote's current branch with changes from the local repository. (Unless the remote is configured with receive.denyCurrentBranch=updateInstead.)
To make working with such non-bare remotes easier, sync pushes not only
local master to remote master, but also to remote synced/master (and
similar with other branches). When git-annex sync is later run on the
remote, it will merge the synced/ branches that the repository has
received.
Some special remotes contain a tree of files that can be imported
and/or exported, and syncing with these remotes behaves differently.
See git-annex-import(1) and git-annex-export(1) for details
about how importing and exporting work; syncing with such a remote
is essentially an import followed by an export. In many cases,
importing needs to download content from the remote, and so sync will
only import when the --content option is used. (And exporting only
ever happens when --content is used.) The remote's
remote.<name>.annex-tracking-branch also must be configured, and
have the same value as the currently checked out branch.
OPTIONS
[remote]By default, all remotes are synced, except for remotes that have
remote.<name>.annex-syncset to false. By specifying the names of remotes (or remote groups), you can control which ones to sync with.--fastOnly sync with the remotes with the lowest annex-cost value configured.
When a list of remotes (or remote groups) is provided, it picks from amoung those, otherwise it picks from amoung all remotes.
--only-annex-a,--not-only-annexOnly sync the git-annex branch and annexed content with remotes, not other git branches.
This avoids pulling and pushing other branches, and it avoids committing any local changes. It's up to you to use regular git commands to do that.
The
annex.synconlyannexconfiguration can be set to true to make this be the default behavior ofgit-annex sync. To override such a setting, use--not-only-annex.When this is combined with --no-content, only the git-annex branch will be synced.
--commit,--no-commitA commit is done by default (unless
annex.autocommitis set to false).Use --no-commit to avoid committing local changes.
--message=msgUse this option to specify a commit message.
--pull,--no-pullBy default, syncing pulls from remotes and imports from some special remotes. Use --no-pull to disable all pulling.
When
remote.<name>.annex-pullorremote.<name>.annex-syncare set to false, pulling is disabled for those remotes, and using--pullwill not enable it.--push,--no-pushBy default, syncing pushes changes to remotes and exports to some special remotes. Use --no-push to disable all pushing.
When
remote.<name>.annex-pushorremote.<name>.annex-syncare set to false, orremote.<name>.annex-readonlyis set to true, pushing is disabled for those remotes, and using--pushwill not enable it.--content,--no-contentNormally, syncing does not transfer the contents of annexed files. The --content option causes the content of annexed files to also be uploaded and downloaded as necessary, to sync the content between the repository and its remotes.
The
annex.synccontentconfiguration can be set to true to make content be synced by default.Normally this tries to get each annexed file that is in the working tree and whose content the local repository does not yet have, from any remote that it's syncing with that has a copy, and then copies each file to every remote that it is syncing with. This behavior can be overridden by configuring the preferred content of repositories. See git-annex-preferred-content(1).
--content-of=path-C pathWhile --content operates on all annexed files, --content-of allows limiting the transferred files to ones in a given location.
This option can be repeated multiple times with different paths.
--all-AThis 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=orexclude=will only match the version of files currently in the work tree, but not past versions of files.--jobs=N-JNEnables parallel syncing with up to the specified number of jobs running at once. For example:
-J10Setting this to "cpus" will run one job per CPU core.
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.
--allow-unrelated-histories,--no-allow-unrelated-historiesPassed on to
git merge, to control whether or not to merge histories that do not share a common ancestor.--resolvemerge,--no-resolvemergeBy default, 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.variant-A" and "foo.variant-B". (See git-annex-resolvemerge(1) for details.)
Use
--no-resolvemergeto disable this automatic merge conflict resolution. It can also be disabled by settingannex.resolvemergeto false.--backendSpecifies which key-value backend to use when adding files, or when importing from a special remote.
--cleanupRemoves the local and remote
synced/branches, which were created and pushed bygit-annex sync. This option prevents all other syncing activities.This can come in handy when you've synced a change to remotes and now want to reset your master branch back before that change. So you run
git resetand force-push the master branch to remotes, only to find that the nextgit annex mergeorgit annex syncbrings the changes back. Why? Because thesynced/masterbranch is hanging around and still has the change in it. Cleaning up thesynced/branches prevents that problem.Also the git-annex-common-options(1) can be used.
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.

With approptiate locking to prevent concurrency problems. As is the case extensively throughout git-annex, although users seem to keep expecting that to not be the case no matter how many times I assure them it is.
git-annex sync pulls before pushing. If another push occurs at the same time, the push might fail, but retrying the pull will not avoid that same situation occurring again. I don't think it makes sense for git-annex sync to retry an arbitrary number of times.
When a push would result in a non-fast-forward merge, git-annex-sync currently fails. Maybe instead, pull and retry pushing? This happens in the context of several processes trying to push to the same git-annex repo.
Also, the docs mention synced/master, but it's synced/current-branch.