1alternate object database:: 2 Via the alternates mechanism, a repository can inherit part of its 3 object database from another object database, which is called 4 "alternate". 5 6blob object:: 7 Untyped object, e.g. the contents of a file. 8 9branch:: 10 A non-cyclical graph of revisions, i.e. the complete history of 11 a particular revision, which is called the branch head. The 12 branch heads are stored in `$GIT_DIR/refs/heads/`. 13 14cache:: 15 Obsolete for: index. 16 17chain:: 18 A list of objects, where each object in the list contains a 19 reference to its successor (for example, the successor of a commit 20 could be one of its parents). 21 22changeset:: 23 BitKeeper/cvsps speak for "commit". Since git does not store 24 changes, but states, it really does not make sense to use 25 the term "changesets" with git. 26 27checkout:: 28 The action of updating the working tree to a revision which was 29 stored in the object database. 30 31clean:: 32 A working tree is clean, if it corresponds to the revision 33 referenced by the current head. Also see "dirty". 34 35commit:: 36 As a verb: The action of storing the current state of the index in the 37 object database. The result is a revision. 38 As a noun: Short hand for commit object. 39 40commit object:: 41 An object which contains the information about a particular 42 revision, such as parents, committer, author, date and the 43 tree object which corresponds to the top directory of the 44 stored revision. 45 46core git:: 47 Fundamental data structures and utilities of git. Exposes only 48 limited source code management tools. 49 50DAG:: 51 Directed acyclic graph. The commit objects form a directed acyclic 52 graph, because they have parents (directed), and the graph of commit 53 objects is acyclic (there is no chain which begins and ends with the 54 same object). 55 56dircache:: 57 You are *waaaaay* behind. 58 59dirty:: 60 A working tree is said to be dirty if it contains modifications 61 which have not been committed to the current branch. 62 63directory:: 64 The list you get with "ls" :-) 65 66ent:: 67 Favorite synonym to "tree-ish" by some total geeks. See 68 `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth 69 explanation. 70 71fast forward:: 72 A fast-forward is a special type of merge where you have 73 a revision and you are "merging" another branch's changes 74 that happen to be a descendant of what you have. 75 In such these cases, you do not make a new merge commit but 76 instead just update to his revision. This will happen 77 frequently on a tracking branch of a remote repository. 78 79fetch:: 80 Fetching a branch means to get the branch's head ref from a 81 remote repository, to find out which objects are missing from 82 the local object database, and to get them, too. 83 84file system:: 85 Linus Torvalds originally designed git to be a user space file 86 system, i.e. the infrastructure to hold files and directories. 87 That ensured the efficiency and speed of git. 88 89git archive:: 90 Synonym for repository (for arch people). 91 92hash:: 93 In git's context, synonym to object name. 94 95head:: 96 The top of a branch. It contains a ref to the corresponding 97 commit object. 98 99head ref:: 100 A ref pointing to a head. Often, this is abbreviated to "head". 101 Head refs are stored in `$GIT_DIR/refs/heads/`. 102 103index:: 104 A collection of files with stat information, whose contents are 105 stored as objects. The index is a stored version of your working 106 tree. Truth be told, it can also contain a second, and even a third 107 version of a working tree, which are used when merging. 108 109index entry:: 110 The information regarding a particular file, stored in the index. 111 An index entry can be unmerged, if a merge was started, but not 112 yet finished (i.e. if the index contains multiple versions of 113 that file). 114 115master:: 116 The default branch. Whenever you create a git repository, a branch 117 named "master" is created, and becomes the active branch. In most 118 cases, this contains the local development. 119 120 121merge:: 122 To merge branches means to try to accumulate the changes since a 123 common ancestor and apply them to the first branch. An automatic 124 merge uses heuristics to accomplish that. Evidently, an automatic 125 merge can fail. 126 127object:: 128 The unit of storage in git. It is uniquely identified by 129 the SHA1 of its contents. Consequently, an object can not 130 be changed. 131 132object database:: 133 Stores a set of "objects", and an individual object is identified 134 by its object name. The objects usually live in `$GIT_DIR/objects/`. 135 136object identifier:: 137 Synonym for object name. 138 139object name:: 140 The unique identifier of an object. The hash of the object's contents 141 using the Secure Hash Algorithm 1 and usually represented by the 40 142 character hexadecimal encoding of the hash of the object (possibly 143 followed by a white space). 144 145object type: 146 One of the identifiers "commit","tree","tag" and "blob" describing 147 the type of an object. 148 149octopus:: 150 To merge more than two branches. Also denotes an intelligent 151 predator. 152 153origin:: 154 The default upstream branch. Most projects have one upstream 155 project which they track, and by default 'origin' is used for 156 that purpose. New updates from upstream will be fetched into 157 this branch; you should never commit to it yourself. 158 159pack:: 160 A set of objects which have been compressed into one file (to save 161 space or to transmit them efficiently). 162 163pack index:: 164 The list of identifiers, and other information, of the objects in a 165 pack, to assist in efficiently accessing the contents of a pack. 166 167parent:: 168 A commit object contains a (possibly empty) list of the logical 169 predecessor(s) in the line of development, i.e. its parents. 170 171pickaxe:: The term pickaxe refers to an option to the diffcore routines 172 that help select changes that add or delete a given text string. 173 With the --pickaxe-all option, it can be used to view the 174 full changeset that introduced or removed, say, a particular 175 line of text. See gitlink:git-diff[1]. 176 177plumbing:: 178 Cute name for core git. 179 180porcelain:: 181 Cute name for programs and program suites depending on core git, 182 presenting a high level access to core git. Porcelains expose 183 more of a SCM interface than the plumbing. 184 185pull:: 186 Pulling a branch means to fetch it and merge it. 187 188push:: 189 Pushing a branch means to get the branch's head ref from a remote 190 repository, find out if it is an ancestor to the branch's local 191 head ref is a direct, and in that case, putting all objects, which 192 are reachable from the local head ref, and which are missing from 193 the remote repository, into the remote object database, and updating 194 the remote head ref. If the remote head is not an ancestor to the 195 local head, the push fails. 196 197reachable:: 198 An object is reachable from a ref/commit/tree/tag, if there is a 199 chain leading from the latter to the former. 200 201rebase:: 202 To clean a branch by starting from the head of the main line of 203 development ("master"), and reapply the (possibly cherry-picked) 204 changes from that branch. 205 206ref:: 207 A 40-byte hex representation of a SHA1 pointing to a particular 208 object. These may be stored in `$GIT_DIR/refs/`. 209 210refspec:: 211 A refspec is used by fetch and push to describe the mapping 212 between remote ref and local ref. They are combined with 213 a colon in the format <src>:<dst>, preceded by an optional 214 plus sign, +. For example: 215 `git fetch $URL refs/heads/master:refs/heads/origin` 216 means "grab the master branch head from the $URL and store 217 it as my origin branch head". 218 And `git push $URL refs/heads/master:refs/heads/to-upstream` 219 means "publish my master branch head as to-upstream master head 220 at $URL". See also gitlink:git-push[1] 221 222repository:: 223 A collection of refs together with an object database containing 224 all objects, which are reachable from the refs, possibly accompanied 225 by meta data from one or more porcelains. A repository can 226 share an object database with other repositories. 227 228resolve:: 229 The action of fixing up manually what a failed automatic merge 230 left behind. 231 232revision:: 233 A particular state of files and directories which was stored in 234 the object database. It is referenced by a commit object. 235 236rewind:: 237 To throw away part of the development, i.e. to assign the head to 238 an earlier revision. 239 240SCM:: 241 Source code management (tool). 242 243SHA1:: 244 Synonym for object name. 245 246tracking branch:: 247 A regular git branch that is used to follow changes from 248 another repository. A tracking branch should not contain 249 direct modifications or made commits made locally. 250 A tracking branch can usually be identified as the 251 right-hand-side ref in a Pull: refspec. 252 253tree object:: 254 An object containing a list of file names and modes along with refs 255 to the associated blob and/or tree objects. A tree is equivalent 256 to a directory. 257 258tree:: 259 Either a working tree, or a tree object together with the 260 dependent blob and tree objects (i.e. a stored representation 261 of a working tree). 262 263tree-ish:: 264 A ref pointing to either a commit object, a tree object, or a 265 tag object pointing to a tag or commit or tree object. 266 267tag object:: 268 An object containing a ref pointing to another object, which can 269 contain a message just like a commit object. It can also 270 contain a (PGP) signature, in which case it is called a "signed 271 tag object". 272 273tag:: 274 A ref pointing to a tag or commit object. In contrast to a head, 275 a tag is not changed by a commit. Tags (not tag objects) are 276 stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with 277 a Lisp tag (which is called object type in git's context). 278 A tag is most typically used to mark a particular point in the 279 commit ancestry chain. 280 281unmerged index: 282 An index which contains unmerged index entries. 283 284working tree:: 285 The set of files and directories currently being worked on, 286 i.e. you can work in your working tree without using git at all. 287