mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/doc/git-annex-push.mdwn

148 lines
5.1 KiB
Text
Raw Normal View History

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.)
push: Support --cleanup This option is not specific to sync, so it seemed it should be in either pull or push as well as sync. Since it does modify the remote, it seems better to have it in push; the modification of the local repo pulls in the direction of pull, but not hard enough. Maybe it would be better to have it in both? Sponsored-by: Luke Shumaker on Patreon
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
document -C behavior with exporttree remotes
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]`
mention that the default is only available remotes
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`
Only pull the git-annex branch and annexed content from remotes,
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
will be pulled.
sync: Added -g as a short option for --no-content I anticipate that if sync is transitioned to syncing content by default, people will want a short option. And in repositories where annex.synccontent = true, they already would. And pull and push sync content by default, so a short option is useful with them too. Mnemonic: -g makes only git data be synced Also, -a makes only annex data be synced. Would have preferred -c, which would complement -C, but it was already taken to set git configs. Sponsored-by: Noam Kremen on Patreon
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
sync: Added -g as a short option for --no-content I anticipate that if sync is transitioned to syncing content by default, people will want a short option. And in repositories where annex.synccontent = true, they already would. And pull and push sync content by default, so a short option is useful with them too. Mnemonic: -g makes only git data be synced Also, -a makes only annex data be synced. Would have preferred -c, which would complement -C, but it was already taken to set git configs. Sponsored-by: Noam Kremen on Patreon
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.
document -C behavior with exporttree remotes
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.
push: Support --cleanup This option is not specific to sync, so it seemed it should be in either pull or push as well as sync. Since it does modify the remote, it seems better to have it in push; the modification of the local repo pulls in the direction of pull, but not hard enough. Maybe it would be better to have it in both? Sponsored-by: Luke Shumaker on Patreon
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)
document git-annex satisfy
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.
Reference in a new issue Copy permalink