SYNOPSIS
--------
+[verse]
'git-bundle' create <file> [git-rev-list args]
'git-bundle' verify <file>
'git-bundle' list-heads <file> [refname...]
rsync, http) cannot be used. This command provides support for
git-fetch and git-pull to operate by packaging objects and references
in an archive at the originating machine, then importing those into
-another repository using gitlink:git-fetch[1] and gitlink:git-pull[1]
+another repository using linkgit:git-fetch[1] and linkgit:git-pull[1]
after moving the archive by some means (i.e., by sneakernet). As no
direct connection between repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
printed out.
unbundle <file>::
- Passes the objects in the bundle to gitlink:git-index-pack[1]
+ Passes the objects in the bundle to linkgit:git-index-pack[1]
for storage in the repository, then prints the names of all
defined references. If a reflist is given, only references
matching those in the given list are printed. This command is
really plumbing, intended to be called only by
- gitlink:git-fetch[1].
+ linkgit:git-fetch[1].
[git-rev-list-args...]::
A list of arguments, acceptable to git-rev-parse and
available. This is principally of use to git-fetch, which
expects to receive only those references asked for and not
necessarily everything in the pack (in this case, git-bundle is
- acting like gitlink:git-fetch-pack[1]).
+ acting like linkgit:git-fetch-pack[1]).
SPECIFYING REFERENCES
---------------------
For whatever reason, direct connection between A and B is not allowed,
but we can move data from A to B via some mechanism (CD, email, etc).
We want to update R2 with developments made on branch master in R1.
+
+To create the bundle you have to specify the basis. You have some options:
+
+- Without basis.
++
+This is useful when sending the whole history.
+
+------------
+$ git bundle create mybundle master
+------------
+
+- Using temporally tags.
++
We set a tag in R1 (lastR2bundle) after the previous such transport,
and move it afterwards to help build the bundle.
-in R1 on A:
+------------
$ git-bundle create mybundle master ^lastR2bundle
$ git tag -f lastR2bundle master
+------------
-(move mybundle from A to B by some mechanism)
+- Using a tag present in both repositories
-in R2 on B:
-$ git-bundle verify mybundle
-$ git-fetch mybundle refspec
+------------
+$ git bundle create mybundle master ^v1.0.0
+------------
-where refspec is refInBundle:localRef
+- A basis based on time.
+------------
+$ git bundle create mybundle master --since=10.days.ago
+------------
+
+- With a limit on the number of commits
+
+------------
+$ git bundle create mybundle master -n 10
+------------
+
+Then you move mybundle from A to B, and in R2 on B:
+
+------------
+$ git-bundle verify mybundle
+$ git-fetch mybundle master:localRef
+------------
-Also, with something like this in your config:
+With something like this in the config in R2:
+------------------------
[remote "bundle"]
url = /home/me/tmp/file.bdl
fetch = refs/heads/*:refs/remotes/origin/*
+------------------------
You can first sneakernet the bundle file to ~/tmp/file.bdl and
-then these commands:
+then these commands on machine B:
+------------
$ git ls-remote bundle
$ git fetch bundle
$ git pull bundle
+------------
would treat it as if it is talking with a remote side over the
network.
GIT
---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite