@@ -23,8 +23,9 @@ the "offline" transfer of Git objects without an active "server"
23
23
sitting on the other side of the network connection.
24
24
25
25
They can be used to create both incremental and full backups of a
26
- repository, and to relay the state of the references in one repository
27
- to another.
26
+ repository (see the "full backup" example in "EXAMPLES"), and to relay
27
+ the state of the references in one repository to another (see the second
28
+ example).
28
29
29
30
Git commands that fetch or otherwise "read" via protocols such as
30
31
`ssh://` and `https://` can also operate on bundle files. It is
@@ -34,8 +35,6 @@ contained within it with linkgit:git-ls-remote[1]. There's no
34
35
corresponding "write" support, i.e.a 'git push' into a bundle is not
35
36
supported.
36
37
37
- See the "EXAMPLES" section below for examples of how to use bundles.
38
-
39
38
BUNDLE FORMAT
40
39
-------------
41
40
@@ -132,7 +131,7 @@ SPECIFYING REFERENCES
132
131
---------------------
133
132
134
133
Revisions must be accompanied by reference names to be packaged in a
135
- bundle.
134
+ bundle. Alternatively `--all` can be used to package all refs.
136
135
137
136
More than one reference may be packaged, and more than one set of prerequisite objects can
138
137
be specified. The objects packaged are those not contained in the
@@ -203,8 +202,6 @@ It is okay to err on the side of caution, causing the bundle file
203
202
to contain objects already in the destination, as these are ignored
204
203
when unpacking at the destination.
205
204
206
- If you want to match `git clone --mirror`, which would include your
207
- refs such as `refs/remotes/*`, use `--all`.
208
205
If you want to provide the same set of refs that a clone directly
209
206
from the source repository would get, use `--branches --tags` for
210
207
the `<git-rev-list-args>`.
@@ -216,8 +213,34 @@ bundle.
216
213
EXAMPLES
217
214
--------
218
215
219
- Assume you want to transfer the history from a repository R1 on machine A
220
- to another repository R2 on machine B.
216
+ We'll discuss two cases:
217
+
218
+ 1. Taking a full backup of a repository
219
+ 2. Transferring the history of a repository to another machine when the
220
+ two machines have no direct connection
221
+
222
+ First let's consider a full backup of the repository. The following
223
+ command will take a full backup of the repository in the sense that all
224
+ refs are included in the bundle:
225
+
226
+ ----------------
227
+ $ git bundle create backup.bundle --all
228
+ ----------------
229
+
230
+ But note again that this is only for the refs, i.e. you will only
231
+ include refs and commits reachable from those refs. You will not
232
+ include other local state, such as the contents of the index, working
233
+ tree, the stash, per-repository configuration, hooks, etc.
234
+
235
+ You can later recover that repository by using for example
236
+ linkgit:git-clone[1]:
237
+
238
+ ----------------
239
+ $ git clone backup.bundle <new directory>
240
+ ----------------
241
+
242
+ For the next example, assume you want to transfer the history from a
243
+ repository R1 on machine A to another repository R2 on machine B.
221
244
For whatever reason, direct connection between A and B is not allowed,
222
245
but we can move data from A to B via some mechanism (CD, email, etc.).
223
246
We want to update R2 with development made on the branch master in R1.
@@ -321,6 +344,24 @@ You can also see what references it offers:
321
344
$ git ls-remote mybundle
322
345
----------------
323
346
347
+ DISCUSSION
348
+ ----------
349
+
350
+ A naive way to make a full backup of a repository is to use something to
351
+ the effect of `cp -r <repo> <destination>`. This is discouraged since
352
+ the repository could be written to during the copy operation. In turn
353
+ some files at `<destination>` could be corrupted.
354
+
355
+ This is why it is recommended to use Git tooling for making repository
356
+ backups, either with this command or with e.g. linkgit:git-clone[1].
357
+ But keep in mind that these tools will not help you backup state other
358
+ than refs and commits. In other words they will not help you backup
359
+ contents of the index, working tree, the stash, per-repository
360
+ configuration, hooks, etc.
361
+
362
+ See also linkgit:gitfaq[7], section "TRANSFERS" for a discussion of the
363
+ problems associated with file syncing across systems.
364
+
324
365
FILE FORMAT
325
366
-----------
326
367
0 commit comments