Move objects and refs by archive
gitbundle create <file> <git -rev -list -args> gitbundle verify <file> gitbundle list -heads <file> [<refname> ...] gitbundle unbundle <file> [<refname> ...]
create <file> Used to create a bundle named file . This requires the git-rev -list -args arguments to define the bundle contents .
verify <file> Used to check that a bundle file is valid and will apply cleanly to the current repository . This includes checks on the bundle format itself as well as checking that the prerequisite commits exist and are fully linked in the current repository . gitbundle prints a list of missing commits, if any, and exits with a non -zero status .
list -heads <file> Lists the references defined in the bundle . If followed by a list of references, only references matching those given are printed out .
unbundle <file> Passes the objects in the bundle to gitindex -pack for storage in the repository, then prints the names of all defined references . If a list of references is given, only references matching those in the list are printed . This command is really plumbing, intended to be called only by gitfetch .
<git -rev -list -args> A list of arguments, acceptable to gitrev -parse and gitrev -list (and containing a named ref, see SPECIFYING REFERENCES below), that specifies the specific objects and references to transport . For example, master~10. .master causes the current master reference to be packaged along with all objects added since its 10th ancestor commit . There is no explicit limit to the number of references and objects that may be packaged .
[<refname> ...] A list of references used to limit the references reported as available . This is principally of use to gitfetch ,which expects to receive only those references asked for and not necessarily everything in the pack (in this case, gitbundle acts like gitfetch -pack ).
machineA$ cd R1 machineA$ git bundle create file .bundle master machineA$ git tag -f lastR2bundle master .RE Then you transfer file .bundle to the target machine B . Because this bundle does not require any existing object to be extracted, you can create a new repository on machine B by cloning from it: .RS 4
machineB$ git clone -b master /home/me/tmp/file .bundle R2 .RE This will define a remote called "origin" in the resulting repository that lets you fetch and pull from the bundle . The $GIT_DIR/config file in R2 will have an entry like this: .RS 4
[remote "origin"] url = /home/me/tmp/file .bundle fetch = refs/heads/*:refs/remotes/origin/* .RE To update the resulting mine .git repository, you can fetch or pull after replacing the bundle stored at /home/me/tmp/file .bundle with incremental updates . After working some more in the original repository, you can create an incremental bundle to update the other repository: .RS 4
machineA$ cd R1 machineA$ git bundle create file .bundle lastR2bundle . .master machineA$ git tag -f lastR2bundle master .RE You then transfer the bundle to the other machine to replace /home/me/tmp/file .bundle, and pull from it . .RS 4
machineB$ cd R2 machineB$ git pull .RE If you know up to what commit the intended recipient repository should have the necessary objects, you can use that knowledge to specify the basis, giving a cut -off point to limit the revisions and objects that go in the resulting bundle . The previous example used the lastR2bundle tag for this purpose, but you can use any other options that you would give to the git-log (1)command . Here are more examples: You can use a tag that is present in both: .RS 4
$ git bundle create mybundle v1 .0 .0 . .master .RE You can use a basis based on time: .RS 4
$ git bundle create mybundle --since=10 .days master .RE You can use the number of commits: .RS 4
$ git bundle create mybundle -10 master .RE You can run git-bundle verify to see if you can extract from a bundle that was created with a basis: .RS 4
$ git bundle verify mybundle .RE This will list what commits you must have in order to extract from the bundle and will error out if you do not have them . A bundle from a recipient repository point of view is just like a regular repository which it fetches or pulls from . You can, for example, map references when fetching: .RS 4
$ git fetch mybundle master:localRef .RE You can also see what references it offers: .RS 4
$ git ls -remote mybundle .RE