1git-bundle(1) 2============= 3 4NAME 5---- 6git-bundle - Move objects and refs by archive 7 8 9SYNOPSIS 10-------- 11[verse] 12'git-bundle' create <file> [git-rev-list args] 13'git-bundle' verify <file> 14'git-bundle' list-heads <file> [refname...] 15'git-bundle' unbundle <file> [refname...] 16 17DESCRIPTION 18----------- 19 20Some workflows require that one or more branches of development on one 21machine be replicated on another machine, but the two machines cannot 22be directly connected so the interactive git protocols (git, ssh, 23rsync, http) cannot be used. This command provides support for 24git-fetch and git-pull to operate by packaging objects and references 25in an archive at the originating machine, then importing those into 26another repository using gitlink:git-fetch[1] and gitlink:git-pull[1] 27after moving the archive by some means (i.e., by sneakernet). As no 28direct connection between repositories exists, the user must specify a 29basis for the bundle that is held by the destination repository: the 30bundle assumes that all objects in the basis are already in the 31destination repository. 32 33OPTIONS 34------- 35 36create <file>:: 37 Used to create a bundle named 'file'. This requires the 38 git-rev-list arguments to define the bundle contents. 39 40verify <file>:: 41 Used to check that a bundle file is valid and will apply 42 cleanly to the current repository. This includes checks on the 43 bundle format itself as well as checking that the prerequisite 44 commits exist and are fully linked in the current repository. 45 git-bundle prints a list of missing commits, if any, and exits 46 with non-zero status. 47 48list-heads <file>:: 49 Lists the references defined in the bundle. If followed by a 50 list of references, only references matching those given are 51 printed out. 52 53unbundle <file>:: 54 Passes the objects in the bundle to gitlink:git-index-pack[1] 55 for storage in the repository, then prints the names of all 56 defined references. If a reflist is given, only references 57 matching those in the given list are printed. This command is 58 really plumbing, intended to be called only by 59 gitlink:git-fetch[1]. 60 61[git-rev-list-args...]:: 62 A list of arguments, acceptable to git-rev-parse and 63 git-rev-list, that specify the specific objects and references 64 to transport. For example, "master~10..master" causes the 65 current master reference to be packaged along with all objects 66 added since its 10th ancestor commit. There is no explicit 67 limit to the number of references and objects that may be 68 packaged. 69 70 71[refname...]:: 72 A list of references used to limit the references reported as 73 available. This is principally of use to git-fetch, which 74 expects to receive only those references asked for and not 75 necessarily everything in the pack (in this case, git-bundle is 76 acting like gitlink:git-fetch-pack[1]). 77 78SPECIFYING REFERENCES 79--------------------- 80 81git-bundle will only package references that are shown by 82git-show-ref: this includes heads, tags, and remote heads. References 83such as master~1 cannot be packaged, but are perfectly suitable for 84defining the basis. More than one reference may be packaged, and more 85than one basis can be specified. The objects packaged are those not 86contained in the union of the given bases. Each basis can be 87specified explicitly (e.g., ^master~10), or implicitly (e.g., 88master~10..master, master --since=10.days.ago). 89 90It is very important that the basis used be held by the destination. 91It is okay to err on the side of conservatism, causing the bundle file 92to contain objects already in the destination as these are ignored 93when unpacking at the destination. 94 95EXAMPLE 96------- 97 98Assume two repositories exist as R1 on machine A, and R2 on machine B. 99For whatever reason, direct connection between A and B is not allowed, 100but we can move data from A to B via some mechanism (CD, email, etc). 101We want to update R2 with developments made on branch master in R1. 102We set a tag in R1 (lastR2bundle) after the previous such transport, 103and move it afterwards to help build the bundle. 104 105in R1 on A: 106 107------------ 108$ git-bundle create mybundle master ^lastR2bundle 109$ git tag -f lastR2bundle master 110------------ 111 112(move mybundle from A to B by some mechanism) 113 114in R2 on B: 115 116------------ 117$ git-bundle verify mybundle 118$ git-fetch mybundle refspec 119------------ 120 121where refspec is refInBundle:localRef 122 123 124Also, with something like this in your config: 125 126[remote "bundle"] 127 url = /home/me/tmp/file.bdl 128 fetch = refs/heads/*:refs/remotes/origin/* 129 130You can first sneakernet the bundle file to ~/tmp/file.bdl and 131then these commands: 132 133------------ 134$ git ls-remote bundle 135$ git fetch bundle 136$ git pull bundle 137------------ 138 139would treat it as if it is talking with a remote side over the 140network. 141 142Author 143------ 144Written by Mark Levedahl <mdl123@verizon.net> 145 146GIT 147--- 148Part of the gitlink:git[7] suite