git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
# NAME
|
|
|
|
|
|
|
|
|
|
git-annex push - push content to remotes
|
|
|
|
|
|
|
|
|
|
# SYNOPSIS
|
|
|
|
|
|
|
|
|
|
git annex push `[remote ...]`
|
|
|
|
|
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
|
|
|
|
|
This command pushes content to remotes. It uploads
|
|
|
|
|
both git repository content, and the content of annexed files.
|
|
|
|
|
|
|
|
|
|
You can use `git push` and `git-annex copy` by hand to do the same thing as
|
|
|
|
|
this command, but this command handles several details, including making
|
|
|
|
|
sure that the git-annex branch is pushed to the remote.
|
|
|
|
|
|
|
|
|
|
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. Pushing to 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.)
|
|
|
|
|
|
2023-05-17 16:46:22 +00:00
|
|
|
To make working with such non-bare remotes easier, this command pushes not
|
|
|
|
|
only local `master` to remote `master`, but also to remote `synced/master`
|
|
|
|
|
(and similar with other branches). When `git-annex pull` (or `git-annex
|
|
|
|
|
sync`) is later run on the remote, it will merge the `synced/` branches
|
|
|
|
|
that were pushed to it.
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
|
2023-09-22 16:40:40 +00:00
|
|
|
Some special remotes allow exporting a tree of files to them
|
|
|
|
|
(`exporttree=yes`),
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
and this command can be used to push to those remotes as well
|
|
|
|
|
as regular git remotes. See [[git-annex-export]](1) for details
|
|
|
|
|
about how those special remotes work. In order for this command to export
|
|
|
|
|
to a special remote, `remote.<name>.annex-tracking-branch` also must
|
|
|
|
|
be configured, and have the same value as the currently checked out branch.
|
|
|
|
|
|
|
|
|
|
When [[git-annex-adjust]](1) has been used to check out an adjusted branch,
|
|
|
|
|
this command will propagate changes that have been made back to the
|
|
|
|
|
parent branch, without propagating the adjustments.
|
|
|
|
|
|
|
|
|
|
Normally this tries to upload the content of each annexed file that is
|
|
|
|
|
in the working tree, to any remote that it's pushing to that does not have
|
|
|
|
|
a copy. To control which files are uploaded to a remote, configure the preferred
|
|
|
|
|
content of the remote. When a file is not the preferred content of a remote,
|
|
|
|
|
or of the local repository, this command will try to drop the file's content.
|
|
|
|
|
See [[git-annex-preferred-content]](1).
|
|
|
|
|
|
|
|
|
|
# OPTIONS
|
|
|
|
|
|
|
|
|
|
* `[remote]`
|
|
|
|
|
|
2023-08-16 20:03:05 +00:00
|
|
|
By default, this command pushes to all available remotes, except for remotes
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
that have `remote.<name>.annex-push` (or `remote.<name>.annex-sync`)
|
|
|
|
|
set to false or `remote.<name>.annex-readonly` set to true.
|
|
|
|
|
|
|
|
|
|
By specifying the names of remotes (or remote groups), you can control which
|
|
|
|
|
ones to push to.
|
|
|
|
|
|
|
|
|
|
* `--fast`
|
|
|
|
|
|
|
|
|
|
Only push to the remotes with the lowest annex-cost value configured.
|
|
|
|
|
|
|
|
|
|
When a list of remotes (or remote groups) is provided, it picks from
|
|
|
|
|
amoung those, otherwise it picks from amoung all remotes.
|
|
|
|
|
|
|
|
|
|
* `--only-annex` `-a`, `--not-only-annex`
|
|
|
|
|
|
2024-04-18 14:05:11 +00:00
|
|
|
Only push the git-annex branch and annexed content to remotes,
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
not other git branches.
|
|
|
|
|
|
|
|
|
|
The `annex.synconlyannex` configuration can be set to true to make
|
|
|
|
|
this be the default behavior. To override such a setting, use
|
|
|
|
|
`--not-only-annex`.
|
|
|
|
|
|
|
|
|
|
When this is combined with --no-content, only the git-annex branch
|
2024-04-18 14:05:11 +00:00
|
|
|
will be pushed.
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
|
2023-05-17 16:33:57 +00:00
|
|
|
* `--no-content`, `-g`, `--content`
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
|
2023-05-17 16:33:57 +00:00
|
|
|
Use `--no-content` or `-g` to avoid uploading (and dropping) the content
|
|
|
|
|
of annexed files.
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
|
|
|
|
|
If you often use `--no-content`, you can set the `annex.synccontent`
|
|
|
|
|
configuration to false to prevent uploading content by default.
|
|
|
|
|
The `--content` option overrides that configuration.
|
|
|
|
|
|
|
|
|
|
* `--content-of=path` `-C path`
|
|
|
|
|
|
|
|
|
|
Only upload (or drop) annexed files in the given path.
|
|
|
|
|
|
|
|
|
|
This option can be repeated multiple times with different paths.
|
|
|
|
|
|
2023-09-22 16:40:40 +00:00
|
|
|
Note that this option is ignored when syncing with "exporttree=yes"
|
|
|
|
|
remotes.
|
|
|
|
|
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
* `--all` `-A`
|
|
|
|
|
|
|
|
|
|
Usually this command operates on annexed files in the current branch.
|
|
|
|
|
This option makes it operate on all available versions of all annexed files
|
|
|
|
|
(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 pushing with up to the specified number of jobs
|
|
|
|
|
running at once. For example: `-J10`
|
|
|
|
|
|
|
|
|
|
Setting this to "cpus" will run one job per CPU core.
|
|
|
|
|
|
2023-05-17 16:46:22 +00:00
|
|
|
* `--cleanup`
|
|
|
|
|
|
|
|
|
|
Removes the local and remote `synced/` branches, which were created
|
|
|
|
|
and pushed by `git-annex push` or `git-annex sync`. This option
|
|
|
|
|
prevents all other activities.
|
|
|
|
|
|
|
|
|
|
This can come in handy when you've pushed 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 pull` 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.
|
|
|
|
|
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
* Also the [[git-annex-common-options]](1) can be used.
|
|
|
|
|
|
|
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
|
|
[[git-annex]](1)
|
|
|
|
|
|
|
|
|
|
[[git-annex-pull]](1)
|
|
|
|
|
|
|
|
|
|
[[git-annex-sync]](1)
|
|
|
|
|
|
|
|
|
|
[[git-annex-preferred-content]](1)
|
|
|
|
|
|
2023-06-29 18:15:01 +00:00
|
|
|
[[git-annex-satisfy]](1)
|
|
|
|
|
|
git-annex pull and push
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
2023-05-16 20:37:30 +00:00
|
|
|
# AUTHOR
|
|
|
|
|
|
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
|
|
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|