git-annex/doc/git-annex-sync.mdwn
Joey Hess 4a788fbb3b
sync --content now supports --hide-missing adjusted branches
This relies on git ls-files --with-tree, which I'm using in a way that
its man page does not document. Hm. I emailed the git list to try to get
the docs improved, but at least the git test suite does test the same
kind of use case I'm using here.

Performance impact when not in an adjusted branch is limited to some
additional MVar accesses, and a single git call to determine the name of
the current branch. So very minimal.

When in an adjusted branch, the performance impact is
in Annex.WorkTree.lookupFile, which starts doing an equal amount of work
for files that didn't exist as it already did for files that were
unlocked.

This commit was sponsored by Jochen Bartl on Patreon.
2018-10-19 17:51:25 -04:00

151 lines
5.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.
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 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 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,
--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.