1git-annex-sync(1) General Commands Manual git-annex-sync(1)
2
3
4
6 git-annex-sync - synchronize local repository with remotes
7
9 git annex sync [remote ...]
10
12 This command synchronizes the local repository with its remotes.
13
14 The sync process involves first committing any local changes to files
15 that have previously been added to the repository, then fetching and
16 merging the current branch and the git-annex branch from the remote
17 repositories, and finally pushing the changes back to those branches on
18 the remote repositories. You can use standard git commands to do each
19 of those steps by hand, or if you don't want to worry about the de‐
20 tails, you can use sync.
21
22 The content of annexed objects is not synced by default, but the --con‐
23 tent option (see below) can make that also be synchronized.
24
25 When using git-annex, often remotes are not bare repositories, because
26 it's helpful to add remotes for nearby machines that you want to access
27 the same annexed content. Syncing with a non-bare remote will not nor‐
28 mally update the remote's current branch with changes from the local
29 repository. (Unless the remote is configured with receive.denyCurrent‐
30 Branch=updateInstead.)
31
32 To make working with such non-bare remotes easier, sync pushes not only
33 local master to remote master, but also to remote synced/master (and
34 similar with other branches). When git-annex sync is later run on the
35 remote, it will merge the synced/ branches that the repository has re‐
36 ceived.
37
38 Some special remotes contain a tree of files that can be imported
39 and/or exported, and syncing with these remotes behaves differently.
40 See git-annex-import(1) and git-annex-export(1) for details about how
41 importing and exporting work; syncing with such a remote is essentially
42 an import followed by an export. In many cases, importing needs to
43 download content from the remote, and so sync will only import when the
44 --content option is used. (And exporting only ever happens when --con‐
45 tent is used.) The remote's remote.<name>.annex-tracking-branch also
46 must be configured, and have the same value as the currently checked
47 out branch.
48
49 When git-annex-adjust(1) has been used to check out an adjusted branch,
50 running sync will propagate changes that have been made back to the
51 parent branch, without propagating the adjustments. When git-an‐
52 nex-view(1) has been used to check out a view branch, running sync will
53 update the view branch to reflect any changes to the parent branch or
54 metadata.
55
57 [remote]
58
59 By default, all remotes are synced, except for remotes that have
60 remote.<name>.annex-sync set to false. By specifying the names
61 of remotes (or remote groups), you can control which ones to
62 sync with.
63
64 --fast Only sync with the remotes with the lowest annex-cost value con‐
65 figured.
66
67 When a list of remotes (or remote groups) is provided, it picks
68 from amoung those, otherwise it picks from amoung all remotes.
69
70 --only-annex -a, --not-only-annex
71 Only sync the git-annex branch and annexed content with remotes,
72 not other git branches.
73
74 This avoids pulling and pushing other branches, and it avoids
75 committing any local changes. It's up to you to use regular git
76 commands to do that.
77
78 The annex.synconlyannex configuration can be set to true to make
79 this be the default behavior of git-annex sync. To override such
80 a setting, use --not-only-annex.
81
82 When this is combined with --no-content, only the git-annex
83 branch will be synced.
84
85 --commit, --no-commit
86 A commit is done by default (unless annex.autocommit is set to
87 false).
88
89 Use --no-commit to avoid committing local changes.
90
91 --message=msg
92 Use this option to specify a commit message.
93
94 --pull, --no-pull
95 By default, syncing pulls from remotes and imports from some
96 special remotes. Use --no-pull to disable all pulling.
97
98 When remote.<name>.annex-pull or remote.<name>.annex-sync are
99 set to false, pulling is disabled for those remotes, and using
100 --pull will not enable it.
101
102 --push, --no-push
103 By default, syncing pushes changes to remotes and exports to
104 some special remotes. Use --no-push to disable all pushing.
105
106 When remote.<name>.annex-push or remote.<name>.annex-sync are
107 set to false, or remote.<name>.annex-readonly is set to true,
108 pushing is disabled for those remotes, and using --push will not
109 enable it.
110
111 --content, --no-content
112 Normally, syncing does not transfer the contents of annexed
113 files. The --content option causes the content of annexed files
114 to also be uploaded and downloaded as necessary, to sync the
115 content between the repository and its remotes.
116
117 The annex.synccontent configuration can be set to true to make
118 content be synced by default.
119
120 Normally this tries to get each annexed file that is in the
121 working tree and whose content the local repository does not yet
122 have, from any remote that it's syncing with that has a copy,
123 and then copies each file to every remote that it is syncing
124 with. This behavior can be overridden by configuring the pre‐
125 ferred content of repositories. See git-annex-preferred-con‐
126 tent(1).
127
128 --content-of=path -C path
129 While --content operates on all annexed files, --content-of al‐
130 lows limiting the transferred files to ones in a given location.
131
132 This option can be repeated multiple times with different paths.
133
134 --all -A
135 This option, when combined with --content, makes all available
136 versions of all files be synced, when preferred content settings
137 allow.
138
139 Note that preferred content settings that use include= or ex‐
140 clude= will only match the version of files currently in the
141 work tree, but not past versions of files.
142
143 --jobs=N -JN
144 Enables parallel syncing with up to the specified number of jobs
145 running at once. For example: -J10
146
147 Setting this to "cpus" will run one job per CPU core.
148
149 When there are multiple git remotes, pushes will be made to them
150 in parallel. Pulls are not done in parallel because that tends
151 to be less efficient. When --content is synced, the files are
152 processed in parallel as well.
153
154 --allow-unrelated-histories, --no-allow-unrelated-histories
155 Passed on to git merge, to control whether or not to merge his‐
156 tories that do not share a common ancestor.
157
158 --resolvemerge, --no-resolvemerge
159 By default, merge conflicts are automatically handled by sync.
160 When two conflicting versions of a file have been committed,
161 both will be added to the tree, under different filenames. For
162 example, file "foo" would be replaced with "foo.variant-A" and
163 "foo.variant-B". (See git-annex-resolvemerge(1) for details.)
164
165 Use --no-resolvemerge to disable this automatic merge conflict
166 resolution. It can also be disabled by setting annex.resolve‐
167 merge to false.
168
169 --backend
170 Specifies which key-value backend to use when adding files, or
171 when importing from a special remote.
172
173 --cleanup
174 Removes the local and remote synced/ branches, which were cre‐
175 ated and pushed by git-annex sync. This option prevents all
176 other syncing activities.
177
178 This can come in handy when you've synced a change to remotes
179 and now want to reset your master branch back before that
180 change. So you run git reset and force-push the master branch to
181 remotes, only to find that the next git annex merge or git annex
182 sync brings the changes back. Why? Because the synced/master
183 branch is hanging around and still has the change in it. Clean‐
184 ing up the synced/ branches prevents that problem.
185
186 Also the git-annex-common-options(1) can be used.
187
189 git-annex(1)
190
191 git-annex-preferred-content(1)
192
194 Joey Hess <id@joeyh.name>
195
196 git-annex-sync(1)