| blob | 1a678a98eb4d952769b48b0430461b5c92ba9983 |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 git-bundle(1) Manual Page
407 </h1>
410 <p>git-bundle -
411 Move objects and refs by archive
412 </p>
413 </div>
414 </div>
418 <div class="verseblock-content"><em>git bundle</em> create <file> <git-rev-list-args>
423 </div></div>
424 </div>
427 <div class="paragraph"><p>Some workflows require that one or more branches of development on one
428 machine be replicated on another machine, but the two machines cannot
429 be directly connected, and therefore the interactive git protocols (git,
430 ssh, rsync, http) cannot be used. This command provides support for
432 in an archive at the originating machine, then importing those into
434 after moving the archive by some means (e.g., by sneakernet). As no
435 direct connection between the repositories exists, the user must specify a
436 basis for the bundle that is held by the destination repository: the
437 bundle assumes that all objects in the basis are already in the
438 destination repository.</p></div>
439 </div>
445 </dt>
446 <dd>
447 <p>
450 </p>
451 </dd>
454 </dt>
455 <dd>
456 <p>
457 Used to check that a bundle file is valid and will apply
458 cleanly to the current repository. This includes checks on the
459 bundle format itself as well as checking that the prerequisite
460 commits exist and are fully linked in the current repository.
462 with a non-zero status.
463 </p>
464 </dd>
467 </dt>
468 <dd>
469 <p>
470 Lists the references defined in the bundle. If followed by a
471 list of references, only references matching those given are
472 printed out.
473 </p>
474 </dd>
477 </dt>
478 <dd>
479 <p>
481 for storage in the repository, then prints the names of all
482 defined references. If a list of references is given, only
483 references matching those in the list are printed. This command is
485 </p>
486 </dd>
489 </dt>
490 <dd>
491 <p>
494 below), that specifies the specific objects and references
496 current master reference to be packaged along with all objects
497 added since its 10th ancestor commit. There is no explicit
498 limit to the number of references and objects that may be
499 packaged.
500 </p>
501 </dd>
504 </dt>
505 <dd>
506 <p>
507 A list of references used to limit the references reported as
509 expects to receive only those references asked for and not
512 </p>
513 </dd>
514 </dl></div>
515 </div>
521 defining the basis. More than one reference may be packaged, and more
522 than one basis can be specified. The objects packaged are those not
523 contained in the union of the given bases. Each basis can be
527 It is okay to err on the side of caution, causing the bundle file
528 to contain objects already in the destination, as these are ignored
529 when unpacking at the destination.</p></div>
530 </div>
533 <div class="paragraph"><p>Assume you want to transfer the history from a repository R1 on machine A
534 to another repository R2 on machine B.
535 For whatever reason, direct connection between A and B is not allowed,
536 but we can move data from A to B via some mechanism (CD, email, etc.).
537 We want to update R2 with development made on the branch master in R1.</p></div>
538 <div class="paragraph"><p>To bootstrap the process, you can first create a bundle that does not have
539 any basis. You can use a tag to remember up to what commit you last
540 processed, in order to make it easy to later update the other repository
541 with an incremental bundle:</p></div>
544 <pre><tt>machineA$ cd R1
545 machineA$ git bundle create file.bundle master
546 machineA$ git tag -f lastR2bundle master</tt></pre>
547 </div></div>
548 <div class="paragraph"><p>Then you transfer file.bundle to the target machine B. If you are creating
549 the repository on machine B, then you can clone from the bundle as if it
550 were a remote repository instead of creating an empty repository and then
551 pulling or fetching objects from the bundle:</p></div>
555 </div></div>
556 <div class="paragraph"><p>This will define a remote called "origin" in the resulting repository that
557 lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
558 have an entry like this:</p></div>
562 url = /home/me/tmp/file.bundle
563 fetch = refs/heads/*:refs/remotes/origin/*</tt></pre>
564 </div></div>
565 <div class="paragraph"><p>To update the resulting mine.git repository, you can fetch or pull after
566 replacing the bundle stored at /home/me/tmp/file.bundle with incremental
567 updates.</p></div>
569 incremental bundle to update the other repository:</p></div>
572 <pre><tt>machineA$ cd R1
573 machineA$ git bundle create file.bundle lastR2bundle..master
574 machineA$ git tag -f lastR2bundle master</tt></pre>
575 </div></div>
577 /home/me/tmp/file.bundle, and pull from it.</p></div>
580 <pre><tt>machineB$ cd R2
581 machineB$ git pull</tt></pre>
582 </div></div>
583 <div class="paragraph"><p>If you know up to what commit the intended recipient repository should
584 have the necessary objects, you can use that knowledge to specify the
585 basis, giving a cut-off point to limit the revisions and objects that go
586 in the resulting bundle. The previous example used the lastR2bundle tag
587 for this purpose, but you can use any other options that you would give to
593 </div></div>
598 </div></div>
603 </div></div>
604 <div class="paragraph"><p>You can run <tt>git-bundle verify</tt> to see if you can extract from a bundle
605 that was created with a basis:</p></div>
609 </div></div>
610 <div class="paragraph"><p>This will list what commits you must have in order to extract from the
611 bundle and will error out if you do not have them.</p></div>
612 <div class="paragraph"><p>A bundle from a recipient repository’s point of view is just like a
613 regular repository which it fetches or pulls from. You can, for example, map
614 references when fetching:</p></div>
618 </div></div>
623 </div></div>
624 </div>
628 </div>
632 </div>
633 </div>
634 </body>
635 </html>