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,
|
2020-02-18 16:42:44 +00:00
|
|
|
then fetching and merging the current branch and the `git-annex` branch
|
2015-03-23 19:36:10 +00:00
|
|
|
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.
|
|
|
|
|
|
2020-02-18 16:42:44 +00:00
|
|
|
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.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
2021-04-01 16:50:19 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
# 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.
|
|
|
|
|
|
2020-04-23 20:08:45 +00:00
|
|
|
When a list of remotes (or remote groups) is provided, it picks from
|
|
|
|
|
amoung those, otherwise it picks from amoung all remotes.
|
|
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
* `--only-annex` `-a`, `--not-only-annex`
|
|
|
|
|
|
2020-02-18 16:42:44 +00:00
|
|
|
Only sync the git-annex branch and annexed content with remotes,
|
|
|
|
|
not other git branches.
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
|
|
|
|
|
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.synconlyannex` configuration can be set to true to make
|
|
|
|
|
this be the default behavior of `git-annex sync`. To override such
|
|
|
|
|
a setting, use `--not-only-annex`.
|
|
|
|
|
|
2020-02-18 16:42:44 +00:00
|
|
|
When this is combined with --no-content, only the git-annex branch
|
|
|
|
|
will be synced.
|
|
|
|
|
|
2015-09-13 17:15:35 +00:00
|
|
|
* `--commit`, `--no-commit`
|
|
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
A commit is done by default (unless `annex.autocommit` is set to false).
|
2017-01-30 20:41:29 +00:00
|
|
|
|
|
|
|
|
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
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
By default, syncing pulls from remotes and imports from some special
|
|
|
|
|
remotes. Use --no-pull to disable all pulling.
|
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
|
|
|
|
|
|
|
|
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`
|
|
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
By default, syncing pushes changes to remotes and exports to some
|
2019-03-09 17:21:49 +00:00
|
|
|
special remotes. Use --no-push to disable all pushing.
|
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
|
|
|
|
|
|
|
|
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.
|
2018-10-19 21:51:25 +00:00
|
|
|
The --content option causes the content of annexed files
|
2021-04-01 16:58:06 +00:00
|
|
|
to also be uploaded and downloaded as necessary, to sync the content
|
|
|
|
|
between the repository and its remotes.
|
2017-02-03 18:31:17 +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
|
|
|
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
|
|
|
|
2020-04-13 16:33:35 +00:00
|
|
|
Normally this tries to get each annexed file that is in the working tree
|
2021-04-01 16:58:06 +00:00
|
|
|
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).
|
2015-05-29 16:12:55 +00:00
|
|
|
|
2017-03-20 20:00:06 +00:00
|
|
|
* `--content-of=path` `-C path`
|
|
|
|
|
|
2018-10-19 21:51:25 +00:00
|
|
|
While --content operates on all annexed files,
|
2017-03-20 20:00:06 +00:00
|
|
|
--content-of allows limiting the transferred files to ones in a given
|
|
|
|
|
location.
|
|
|
|
|
|
|
|
|
|
This option can be repeated multiple times with different paths.
|
|
|
|
|
|
2018-04-04 03:12:04 +00:00
|
|
|
* `--all` `-A`
|
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`
|
|
|
|
|
|
2019-05-10 17:24:31 +00:00
|
|
|
Setting this to "cpus" will run one job per CPU core.
|
|
|
|
|
|
2015-08-14 17:49:55 +00:00
|
|
|
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.
|
|
|
|
|
|
2021-07-19 16:08:24 +00:00
|
|
|
* `--allow-unrelated-histories`, `--no-allow-unrelated-histories`
|
|
|
|
|
|
|
|
|
|
Passed on to `git merge`, to control whether or not to merge
|
|
|
|
|
histories that do not share a common ancestor.
|
|
|
|
|
|
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
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
resolution. It can also be disabled by setting `annex.resolvemerge`
|
2017-06-01 16:46:36 +00:00
|
|
|
to false.
|
|
|
|
|
|
2022-06-29 17:28:08 +00:00
|
|
|
* `--backend`
|
|
|
|
|
|
|
|
|
|
Specifies which key-value backend to use when adding files,
|
|
|
|
|
or when importing from a special remote.
|
|
|
|
|
|
2017-09-28 18:14:07 +00:00
|
|
|
* `--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.
|
|
|
|
|
|
2021-05-10 19:00:13 +00:00
|
|
|
* Also the [[git-annex-common-options]](1) can be used.
|
|
|
|
|
|
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.
|