1object:: 2 The unit of storage in GIT. It is uniquely identified by 3 the SHA1 of its contents. Consequently, an object can not 4 be changed. 5 6SHA1:: 7 A 20-byte sequence (or 41-byte file containing the hex 8 representation and a newline). It is calculated from the 9 contents of an object by the Secure Hash Algorithm 1. 10 11object database:: 12 Stores a set of "objects", and an individial object is identified 13 by its SHA1 (its ref). The objects are either stored as single 14 files, or live inside of packs. 15 16object name:: 17 Synonym for SHA1. 18 19blob object:: 20 Untyped object, i.e. the contents of a file. 21 22tree object:: 23 An object containing a list of blob and/or tree objects. 24 (A tree usually corresponds to a directory without 25 subdirectories). 26 27tree:: 28 Either a working tree, or a tree object together with the 29 dependent blob and tree objects (i.e. a stored representation 30 of a working tree). 31 32cache:: 33 A collection of files whose contents are stored as objects. 34 The cache is a stored version of your working tree. Well, can 35 also contain a second, and even a third version of a working 36 tree, which are used when merging. 37 38cache entry:: 39 The information regarding a particular file, stored in the index. 40 A cache entry can be unmerged, if a merge was started, but not 41 yet finished (i.e. if the cache contains multiple versions of 42 that file). 43 44index:: 45 Contains information about the cache contents, in particular 46 timestamps and mode flags ("stat information") for the files 47 stored in the cache. An unmerged index is an index which contains 48 unmerged cache entries. 49 50working tree:: 51 The set of files and directories currently being worked on. 52 Think "ls -laR" 53 54directory:: 55 The list you get with "ls" :-) 56 57checkout:: 58 The action of updating the working tree to a revision which was 59 stored in the object database. 60 61revision:: 62 A particular state of files and directories which was stored in 63 the object database. It is referenced by a commit object. 64 65commit:: 66 The action of storing the current state of the cache in the 67 object database. The result is a revision. 68 69commit object:: 70 An object which contains the information about a particular 71 revision, such as parents, committer, author, date and the 72 tree object which corresponds to the top directory of the 73 stored revision. 74 75changeset:: 76 BitKeeper/cvsps speak for "commit". Since git does not store 77 changes, but states, it really does not make sense to use 78 the term "changesets" with git. 79 80ent:: 81 Favorite synonym to "tree-ish" by some total geeks. 82 83clean:: 84 A working tree is clean, if it corresponds to the revision 85 referenced by the current head. 86 87dirty:: 88 A working tree is said to be dirty if it contains modifications 89 which have not been committed to the current branch. 90 91head:: 92 The top of a branch. It contains a ref to the corresponding 93 commit object. 94 95branch:: 96 A non-cyclical graph of revisions, i.e. the complete history of 97 a particular revision, which does not (yet) have children, which 98 is called the branch head. The branch heads are stored in 99 $GIT_DIR/refs/heads/. 100 101ref:: 102 A 40-byte hex representation of a SHA1 pointing to a particular 103 object. These are stored in $GIT_DIR/refs/. 104 105head ref:: 106 A ref pointing to a head. Often, this is abbreviated to "head". 107 Head refs are stored in $GIT_DIR/refs/heads/. 108 109tree-ish:: 110 A ref pointing to either a commit object, a tree object, or a 111 tag object pointing to a commit or tree object. 112 113tag object:: 114 An object containing a ref pointing to another object. It can 115 contain a (PGP) signature, in which case it is called "signed 116 tag object". 117 118tag:: 119 A ref pointing to a tag or commit object. In contrast to a head, 120 a tag is not changed by a commit. Tags (not tag objects) are 121 stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with 122 a Lisp tag (which is called object type in git's context). 123 124merge:: 125 To merge branches means to try to accumulate the changes since a 126 common ancestor and apply them to the first branch. An automatic 127 merge uses heuristics to accomplish that. Evidently, an automatic 128 merge can fail. 129 130resolve:: 131 The action of fixing up manually what a failed automatic merge 132 left behind. 133 134repository:: 135 A collection of refs together with an object database containing 136 all objects, which are reachable from the refs. A repository can 137 share an object database with other repositories. 138 139alternate object database:: 140 Via the alternates mechanism, a repository can inherit part of its 141 object database from another object database, which is called 142 "alternate". 143 144reachable:: 145 An object is reachable from a ref/commit/tree/tag, if there is a 146 chain leading from the latter to the former. 147 148chain:: 149 A list of objects, where each object in the list contains a 150 reference to its successor (for example, the successor of a commit 151 could be one of its parents). 152 153parent:: 154 A commit object contains a (possibly empty) list of the logical 155 predecessor(s) in the line of development, i.e. its parents. 156 157fetch:: 158 Fetching a branch means to get the branch's head ref from a 159 remote repository, to find out which objects are missing from 160 the local object database, and to get them, too. 161 162pull:: 163 Pulling a branch means to fetch it and merge it. 164 165push:: 166 Pushing a branch means to get the branch's head ref from a remote 167 repository, find out if it is an ancestor to the branch's local 168 head ref is a direct, and in that case, putting all objects, which 169 are reachable from the local head ref, and which are missing from 170 the remote repository, into the remote object database, and updating 171 the remote head ref. If the remote head is not an ancestor to the 172 local head, the push fails. 173 174pack:: 175 A set of objects which have been compressed into one file (to save 176 space or to transmit them efficiently). 177 178pack index:: 179 Contains offsets into a pack, so the pack can be used instead of 180 the unpacked objects. 181 182plumbing:: 183 Cute name for core git. 184 185porcelain:: 186 Cute name for programs and program suites depending on core git, 187 presenting a high level access to core git. Porcelains expose 188 more of a SCM interface than the plumbing. 189 190object type: 191 One of the identifiers "commit","tree","tag" and "blob" describing 192 the type of an object. 193 194SCM:: 195 Source code management (tool). 196 197dircache:: 198 You are *waaaaay* behind.