1GIT-BUNDLE(1)                     Git Manual                     GIT-BUNDLE(1)
2
3
4

NAME

6       git-bundle - Move objects and refs by archive
7

SYNOPSIS

9           git-bundle create <file> [git-rev-list args]
10           git-bundle verify <file>
11           git-bundle list-heads <file> [refname...]
12           git-bundle unbundle <file> [refname...]
13

DESCRIPTION

15       Some workflows require that one or more branches of development on one
16       machine be replicated on another machine, but the two machines cannot
17       be directly connected so the interactive git protocols (git, ssh,
18       rsync, http) cannot be used. This command provides support for
19       git-fetch and git-pull to operate by packaging objects and references
20       in an archive at the originating machine, then importing those into
21       another repository using git-fetch(1) and git-pull(1) after moving the
22       archive by some means (i.e., by sneakernet). As no direct connection
23       between repositories exists, the user must specify a basis for the
24       bundle that is held by the destination repository: the bundle assumes
25       that all objects in the basis are already in the destination
26       repository.
27

OPTIONS

29       create <file>
30           Used to create a bundle named file. This requires the git-rev-list
31           arguments to define the bundle contents.
32
33       verify <file>
34           Used to check that a bundle file is valid and will apply cleanly to
35           the current repository. This includes checks on the bundle format
36           itself as well as checking that the prerequisite commits exist and
37           are fully linked in the current repository. git-bundle prints a
38           list of missing commits, if any, and exits with non-zero status.
39
40       list-heads <file>
41           Lists the references defined in the bundle. If followed by a list
42           of references, only references matching those given are printed
43           out.
44
45       unbundle <file>
46           Passes the objects in the bundle to git-index-pack(1) for storage
47           in the repository, then prints the names of all defined references.
48           If a reflist is given, only references matching those in the given
49           list are printed. This command is really plumbing, intended to be
50           called only by git-fetch(1).
51
52       [git-rev-list-args...]
53           A list of arguments, acceptable to git-rev-parse and git-rev-list,
54           that specify the specific objects and references to transport. For
55           example, "master~10..master" causes the current master reference to
56           be packaged along with all objects added since its 10th ancestor
57           commit. There is no explicit limit to the number of references and
58           objects that may be packaged.
59
60       [refname...]
61           A list of references used to limit the references reported as
62           available. This is principally of use to git-fetch, which expects
63           to receive only those references asked for and not necessarily
64           everything in the pack (in this case, git-bundle is acting like
65           git-fetch-pack(1)).
66

SPECIFYING REFERENCES

68       git-bundle will only package references that are shown by git-show-ref:
69       this includes heads, tags, and remote heads. References such as master1
70       cannot be packaged, but are perfectly suitable for defining the basis.
71       More than one reference may be packaged, and more than one basis can be
72       specified. The objects packaged are those not contained in the union of
73       the given bases. Each basis can be specified explicitly (e.g.,
74       ^master10), or implicitly (e.g., master~10..master, master
75       --since=10.days.ago).
76
77       It is very important that the basis used be held by the destination. It
78       is okay to err on the side of conservatism, causing the bundle file to
79       contain objects already in the destination as these are ignored when
80       unpacking at the destination.
81

EXAMPLE

83       Assume two repositories exist as R1 on machine A, and R2 on machine B.
84       For whatever reason, direct connection between A and B is not allowed,
85       but we can move data from A to B via some mechanism (CD, email, etc).
86       We want to update R2 with developments made on branch master in R1. We
87       set a tag in R1 (lastR2bundle) after the previous such transport, and
88       move it afterwards to help build the bundle.
89
90       in R1 on A:
91
92
93
94           $ git-bundle create mybundle master ^lastR2bundle
95           $ git tag -f lastR2bundle master
96
97       (move mybundle from A to B by some mechanism)
98
99       in R2 on B:
100
101
102
103           $ git-bundle verify mybundle
104           $ git-fetch mybundle  refspec
105
106       where refspec is refInBundle:localRef
107
108       Also, with something like this in your config:
109
110
111           url = /home/me/tmp/file.bdl
112           fetch = refs/heads/*:refs/remotes/origin/*
113       You can first sneakernet the bundle file to ~/tmp/file.bdl and then
114       these commands:
115
116
117
118           $ git ls-remote bundle
119           $ git fetch bundle
120           $ git pull bundle
121
122       would treat it as if it is talking with a remote side over the network.
123

AUTHOR

125       Written by Mark Levedahl <mdl123@verizon.net>
126

GIT

128       Part of the git(7) suite
129
130
131
132
133Git 1.5.3.3                       10/09/2007                     GIT-BUNDLE(1)
Impressum