e8c9a5c515
Also deletes any tagged pushes that the assistant might have done, since those would also prevent resetting a branch back. This commit was sponsored by andrea rota.
151 lines
5.2 KiB
Markdown
151 lines
5.2 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. 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).
|
|
|
|
When a special remote is configured as an export and is tracking a branch,
|
|
the export will be updated to the current content of the branch.
|
|
See [[git-annex-export]](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.
|
|
|
|
* `--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.
|