1git-annex-sync(1)           General Commands Manual          git-annex-sync(1)
2
3
4

NAME

6       git-annex-sync - synchronize local repository with remotes
7

SYNOPSIS

9       git annex sync [remote ...]
10

DESCRIPTION

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

OPTIONS

50       [remote]
51
52              By default, all remotes are synced, except for remotes that have
53              remote.<name>.annex-sync  set  to false. By specifying the names
54              of remotes (or remote groups), you can  control  which  ones  to
55              sync with.
56
57       --fast Only sync with the remotes with the lowest annex-cost value con‐
58              figured.
59
60              When a list of remotes (or remote groups) is provided, it  picks
61              from amoung those, otherwise it picks from amoung all remotes.
62
63       --only-annex -a, --not-only-annex
64              Only sync the git-annex branch and annexed content with remotes,
65              not other git branches.
66
67              This avoids pulling and pushing other branches,  and  it  avoids
68              committing  any local changes. It's up to you to use regular git
69              commands to do that.
70
71              The annex.synconlyannex configuration can be set to true to make
72              this be the default behavior of git-annex sync. To override such
73              a setting, use --not-only-annex.
74
75              When this is combined  with  --no-content,  only  the  git-annex
76              branch will be synced.
77
78       --commit, --no-commit
79              A  commit  is done by default (unless annex.autocommit is set to
80              false).
81
82              Use --no-commit to avoid committing local changes.
83
84       --message=msg
85              Use this option to specify a commit message.
86
87       --pull, --no-pull
88              By default, syncing pulls from remotes  and  imports  from  some
89              special remotes. Use --no-pull to disable all pulling.
90
91              When  remote.<name>.annex-pull  or  remote.<name>.annex-sync are
92              set to false, pulling is disabled for those remotes,  and  using
93              --pull will not enable it.
94
95       --push, --no-push
96              By  default,  syncing  pushes  changes to remotes and exports to
97              some special remotes. Use --no-push to disable all pushing.
98
99              When remote.<name>.annex-push  or  remote.<name>.annex-sync  are
100              set  to  false,  or remote.<name>.annex-readonly is set to true,
101              pushing is disabled for those remotes, and using --push will not
102              enable it.
103
104       --content, --no-content
105              Normally,  syncing  does  not  transfer  the contents of annexed
106              files.  The --content option causes the content of annexed files
107              to  also  be  uploaded  and downloaded as necessary, to sync the
108              content between the repository and its remotes.
109
110              The annex.synccontent configuration can be set to true  to  make
111              content be synced by default.
112
113              Normally  this  tries  to  get  each annexed file that is in the
114              working tree and whose content the local repository does not yet
115              have,  from  any  remote that it's syncing with that has a copy,
116              and then copies each file to every remote  that  it  is  syncing
117              with.  This  behavior  can be overridden by configuring the pre‐
118              ferred content  of  repositories.  See  git-annex-preferred-con‐
119              tent(1).
120
121       --content-of=path -C path
122              While  --content operates on all annexed files, --content-of al‐
123              lows limiting the transferred files to ones in a given location.
124
125              This option can be repeated multiple times with different paths.
126
127       --all -A
128              This option, when combined with --content, makes  all  available
129              versions of all files be synced, when preferred content settings
130              allow.
131
132              Note that preferred content settings that use  include=  or  ex‐
133              clude=  will  only  match  the version of files currently in the
134              work tree, but not past versions of files.
135
136       --jobs=N -JN
137              Enables parallel syncing with up to the specified number of jobs
138              running at once. For example: -J10
139
140              Setting this to "cpus" will run one job per CPU core.
141
142              When there are multiple git remotes, pushes will be made to them
143              in parallel. Pulls are not done in parallel because  that  tends
144              to  be  less  efficient. When --content is synced, the files are
145              processed in parallel as well.
146
147       --allow-unrelated-histories, --no-allow-unrelated-histories
148              Passed on to git merge, to control whether or not to merge  his‐
149              tories that do not share a common ancestor.
150
151       --resolvemerge, --no-resolvemerge
152              By  default,  merge conflicts are automatically handled by sync.
153              When two conflicting versions of a  file  have  been  committed,
154              both  will  be added to the tree, under different filenames. For
155              example, file "foo" would be replaced with  "foo.variant-A"  and
156              "foo.variant-B". (See git-annex-resolvemerge(1) for details.)
157
158              Use  --no-resolvemerge  to disable this automatic merge conflict
159              resolution. It can also be disabled  by  setting  annex.resolve‐
160              merge to false.
161
162       --cleanup
163              Removes  the  local and remote synced/ branches, which were cre‐
164              ated and pushed by git-annex sync.
165
166              This can come in handy when you've synced a  change  to  remotes
167              and  now  want  to  reset  your  master  branch back before that
168              change. So you run git reset and force-push the master branch to
169              remotes, only to find that the next git annex merge or git annex
170              sync brings the changes back.  Why?  Because  the  synced/master
171              branch  is hanging around and still has the change in it. Clean‐
172              ing up the synced/ branches prevents that problem.
173
174       Also the git-annex-common-options(1) can be used.
175

SEE ALSO

177       git-annex(1)
178
179       git-annex-preferred-content(1)
180

AUTHOR

182       Joey Hess <id@joeyh.name>
183
184                                                             git-annex-sync(1)
Impressum