5df89d58c7
Split out two new commands, git-annex pull and git-annex push. Those plus a git commit are equivilant to git-annex sync. In a sense, git-annex sync conflates 3 things, and it would have been better to have push and pull from the beginning and not sync. Although note that git-annex sync --content is faster than a pull followed by a push, because it only has to walk the tree once, look at preferred content once, etc. So there is some value in git-annex sync in speed, as well as user convenience. And it would be hard to split out pull and push from sync, as far as the implementaton goes. The implementation inside sync was easy, just adjust SyncOptions so it does the right thing. Note that the new commands default to syncing content, unless annex.synccontent is explicitly set to false. I'd like sync to also do that, but that's a hard transition to make. As a start to that transition, I added a note to git-annex-sync.mdwn that it may start to do so in a future version of git-annex. But a real transition would necessarily involve displaying warnings when sync is used without --content, and time. Sponsored-by: Kevin Mueller on Patreon
92 lines
2.5 KiB
Markdown
92 lines
2.5 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.
|
|
|
|
This command first commits any local changes to files that have
|
|
previously been added to the repository. Then it does the equivilant of
|
|
[[git-annex-pull]](1) followed by [[git-annex-push]](1).
|
|
|
|
However, unlike those commands, this command does not transfer annexed
|
|
content by default. This may change in a future version of git-annex.
|
|
|
|
# OPTIONS
|
|
|
|
* `--content`, `--no-content`
|
|
|
|
The --content option causes the content of annexed files
|
|
to also be pulled and pushed.
|
|
|
|
The `annex.synccontent` configuration can be set to true to make
|
|
`--content` be enabled by default.
|
|
|
|
* `--content-of=path` `-C path`
|
|
|
|
This option causes the content of annexed files in the given
|
|
path to also be pulled and pushed.
|
|
|
|
This option can be repeated multiple times with different paths.
|
|
|
|
* `--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`
|
|
|
|
Use this option to disable pulling.
|
|
|
|
When `remote.<name>.annex-sync` is set to false, pulling is disabled
|
|
for that remote, and using `--pull` will not enable it.
|
|
|
|
* `--push`, `--no-push`
|
|
|
|
Use this option to disable pushing.
|
|
|
|
When `remote.<name>.annex-sync` is set to false, pushing is disabled for
|
|
that remote, and using `--push` will not enable it.
|
|
|
|
* `--cleanup`
|
|
|
|
Removes the local and remote `synced/` branches, which were created
|
|
and pushed by `git-annex sync`. This option prevents all other syncing
|
|
activities.
|
|
|
|
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.
|
|
|
|
* Also all options supported by [[git-annex-pull]](1) and
|
|
[[git-annex-push]](1) can be used.
|
|
|
|
* Also the [[git-annex-common-options]](1) can be used.
|
|
|
|
# SEE ALSO
|
|
|
|
[[git-annex]](1)
|
|
|
|
[[git-annex-pull]](1)
|
|
|
|
[[git-annex-push]](1)
|
|
|
|
# AUTHOR
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|