2015-03-23 19:36:10 +00:00
|
|
|
# NAME
|
|
|
|
|
|
|
|
git-annex sync - synchronize local repository with remotes
|
|
|
|
|
|
|
|
# SYNOPSIS
|
|
|
|
|
|
|
|
git annex sync `[remote ...]`
|
|
|
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
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.
2017-04-05 17:04:02 +00:00
|
|
|
This command synchronizes the local repository with its remotes.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2015-06-16 20:50:03 +00:00
|
|
|
The content of annexed objects is not synced by default, but the --content
|
|
|
|
option (see below) can make that also be synchronized.
|
|
|
|
|
2017-05-25 17:43:20 +00:00
|
|
|
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
|
2015-03-23 19:36:10 +00:00
|
|
|
are pushed to the remote, so they can be merged into its working tree
|
|
|
|
by running "git annex sync" on the remote.
|
|
|
|
|
|
|
|
# OPTIONS
|
|
|
|
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
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.
2017-04-05 17:04:02 +00:00
|
|
|
* `[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.
|
|
|
|
|
2015-09-13 17:15:35 +00:00
|
|
|
* `--fast`
|
|
|
|
|
|
|
|
Only sync with the remotes with the lowest annex-cost value configured.
|
|
|
|
|
|
|
|
* `--commit`, `--no-commit`
|
|
|
|
|
2017-01-30 20:41:29 +00:00
|
|
|
A commit is done by default (unless annex.autocommit is set to false).
|
|
|
|
|
|
|
|
Use --no-commit to avoid committing local changes.
|
2015-09-13 17:15:35 +00:00
|
|
|
|
2015-06-16 20:50:03 +00:00
|
|
|
* `--message=msg`
|
|
|
|
|
|
|
|
Use this option to specify a commit message.
|
|
|
|
|
2015-09-13 17:15:35 +00:00
|
|
|
* `--pull`, `--no-pull`
|
2015-03-23 19:36:10 +00:00
|
|
|
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
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.
2017-04-05 17:04:02 +00:00
|
|
|
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.
|
2015-09-13 17:15:35 +00:00
|
|
|
|
|
|
|
* `--push`, `--no-push`
|
|
|
|
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
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.
2017-04-05 17:04:02 +00:00
|
|
|
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.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
2015-09-13 17:15:35 +00:00
|
|
|
* `--content`, `--no-content`
|
2015-03-23 19:36:10 +00:00
|
|
|
|
|
|
|
Normally, syncing does not transfer the contents of annexed files.
|
2015-09-13 17:15:35 +00:00
|
|
|
The --content option causes the content of files in the work tree
|
2017-02-03 18:31:17 +00:00
|
|
|
to also be uploaded and downloaded as necessary.
|
|
|
|
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
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.
2017-04-05 17:04:02 +00:00
|
|
|
The `annex.synccontent` configuration can be set to true to make content
|
2017-02-03 18:31:17 +00:00
|
|
|
be synced by default.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
2015-09-13 17:15:35 +00:00
|
|
|
Normally this tries to get each annexed file in the work tree
|
2015-06-16 20:50:03 +00:00
|
|
|
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).
|
2015-05-29 16:12:55 +00:00
|
|
|
|
2017-03-20 20:00:06 +00:00
|
|
|
* `--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.
|
|
|
|
|
2015-06-16 20:50:03 +00:00
|
|
|
* `--all`
|
2015-03-23 19:36:10 +00:00
|
|
|
|
2015-06-16 20:50:03 +00:00
|
|
|
This option, when combined with `--content`, makes all available versions
|
|
|
|
of all files be synced, when preferred content settings allow.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
2015-06-16 20:50:03 +00:00
|
|
|
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.
|
|
|
|
|
2015-08-14 17:49:55 +00:00
|
|
|
* `--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.
|
|
|
|
|
2017-06-01 16:46:36 +00:00
|
|
|
* `--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.
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
[[git-annex]](1)
|
|
|
|
|
2015-05-29 16:12:55 +00:00
|
|
|
[[git-annex-preferred-content]](1)
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
# AUTHOR
|
|
|
|
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|