633021e135
Users may want sync to only export, or only import and this is broadly analagous to push and pull, so it makes sense to use the same configuration for it.
155 lines
5.4 KiB
Markdown
155 lines
5.4 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.
|
|
|
|
Note that syncing with a remote will not normally update the remote's working
|
|
tree with changes made to the local repository. (Unless it's configured
|
|
with receive.denyCurrentBranch=updateInstead.) 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 and imports from some special 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 and exports to some
|
|
special 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 annexed files
|
|
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 that the local repository
|
|
does not yet have, and then copies each file 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).
|
|
|
|
When `remote.<name>.annex-tracking-branch` is configured for a special remote
|
|
and that branch is checked out, syncing will import changes from
|
|
the remote, merge them into the branch, and export any changes that have
|
|
been committed to the branch back to the remote. See
|
|
See [[git-annex-import]](1) and [[git-annex-export]](1) for details about
|
|
how importing and exporting work.
|
|
|
|
* `--content-of=path` `-C path`
|
|
|
|
While --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` `-A`
|
|
|
|
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.
|
|
|
|
* `--resolvemerge`, `--no-resolvemerge`
|
|
|
|
By 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-resolvemerge` to disable this automatic merge conflict
|
|
resolution. It can also be disabled by setting annex.resolvemerge
|
|
to false.
|
|
|
|
* `--cleanup`
|
|
|
|
Removes the local and remote `synced/` branches, which were created
|
|
and pushed by `git-annex sync`.
|
|
|
|
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 reset` and force-push the master branch to remotes, only
|
|
to find that the next `git annex merge` or `git annex sync` brings the
|
|
changes back. Why? Because the `synced/master` branch is hanging
|
|
around and still has the change in it. Cleaning up the `synced/` branches
|
|
prevents that problem.
|
|
|
|
# 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.
|