1[[def_alternate_object_database]]alternate object database:: 2 Via the alternates mechanism, a <<def_repository,repository>> 3 can inherit part of its <<def_object_database,object database>> 4 from another object database, which is called "alternate". 5 6[[def_bare_repository]]bare repository:: 7 A bare repository is normally an appropriately 8 named <<def_directory,directory>> with a `.git` suffix that does not 9 have a locally checked-out copy of any of the files under 10 revision control. That is, all of the Git 11 administrative and control files that would normally be present in the 12 hidden `.git` sub-directory are directly present in the 13 `repository.git` directory instead, 14 and no other files are present and checked out. Usually publishers of 15 public repositories make bare repositories available. 16 17[[def_blob_object]]blob object:: 18 Untyped <<def_object,object>>, e.g. the contents of a file. 19 20[[def_branch]]branch:: 21 A "branch" is an active line of development. The most recent 22 <<def_commit,commit>> on a branch is referred to as the tip of 23 that branch. The tip of the branch is referenced by a branch 24 <<def_head,head>>, which moves forward as additional development 25 is done on the branch. A single Git 26 <<def_repository,repository>> can track an arbitrary number of 27 branches, but your <<def_working_tree,working tree>> is 28 associated with just one of them (the "current" or "checked out" 29 branch), and <<def_HEAD,HEAD>> points to that branch. 30 31[[def_cache]]cache:: 32 Obsolete for: <<def_index,index>>. 33 34[[def_chain]]chain:: 35 A list of objects, where each <<def_object,object>> in the list contains 36 a reference to its successor (for example, the successor of a 37 <<def_commit,commit>> could be one of its <<def_parent,parents>>). 38 39[[def_changeset]]changeset:: 40 BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not 41 store changes, but states, it really does not make sense to use the term 42 "changesets" with Git. 43 44[[def_checkout]]checkout:: 45 The action of updating all or part of the 46 <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> 47 or <<def_blob_object,blob>> from the 48 <<def_object_database,object database>>, and updating the 49 <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has 50 been pointed at a new <<def_branch,branch>>. 51 52[[def_cherry-picking]]cherry-picking:: 53 In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of 54 changes out of a series of changes (typically commits) and record them 55 as a new series of changes on top of a different codebase. In Git, this is 56 performed by the "git cherry-pick" command to extract the change introduced 57 by an existing <<def_commit,commit>> and to record it based on the tip 58 of the current <<def_branch,branch>> as a new commit. 59 60[[def_clean]]clean:: 61 A <<def_working_tree,working tree>> is clean, if it 62 corresponds to the <<def_revision,revision>> referenced by the current 63 <<def_head,head>>. Also see "<<def_dirty,dirty>>". 64 65[[def_commit]]commit:: 66 As a noun: A single point in the 67 Git history; the entire history of a project is represented as a 68 set of interrelated commits. The word "commit" is often 69 used by Git in the same places other revision control systems 70 use the words "revision" or "version". Also used as a short 71 hand for <<def_commit_object,commit object>>. 72+ 73As a verb: The action of storing a new snapshot of the project's 74state in the Git history, by creating a new commit representing the current 75state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> 76to point at the new commit. 77 78[[def_commit_object]]commit object:: 79 An <<def_object,object>> which contains the information about a 80 particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, 81 author, date and the <<def_tree_object,tree object>> which corresponds 82 to the top <<def_directory,directory>> of the stored 83 revision. 84 85[[def_core_git]]core Git:: 86 Fundamental data structures and utilities of Git. Exposes only limited 87 source code management tools. 88 89[[def_DAG]]DAG:: 90 Directed acyclic graph. The <<def_commit_object,commit objects>> form a 91 directed acyclic graph, because they have parents (directed), and the 92 graph of commit objects is acyclic (there is no <<def_chain,chain>> 93 which begins and ends with the same <<def_object,object>>). 94 95[[def_dangling_object]]dangling object:: 96 An <<def_unreachable_object,unreachable object>> which is not 97 <<def_reachable,reachable>> even from other unreachable objects; a 98 dangling object has no references to it from any 99 reference or <<def_object,object>> in the <<def_repository,repository>>. 100 101[[def_detached_HEAD]]detached HEAD:: 102 Normally the <<def_HEAD,HEAD>> stores the name of a 103 <<def_branch,branch>>, and commands that operate on the 104 history HEAD represents operate on the history leading to the 105 tip of the branch the HEAD points at. However, Git also 106 allows you to <<def_checkout,check out>> an arbitrary 107 <<def_commit,commit>> that isn't necessarily the tip of any 108 particular branch. The HEAD in such a state is called 109 "detached". 110+ 111Note that commands that operate on the history of the current branch 112(e.g. `git commit` to build a new history on top of it) still work 113while the HEAD is detached. They update the HEAD to point at the tip 114of the updated history without affecting any branch. Commands that 115update or inquire information _about_ the current branch (e.g. `git 116branch --set-upstream-to` that sets what remote tracking branch the 117current branch integrates with) obviously do not work, as there is no 118(real) current branch to ask about in this state. 119 120[[def_directory]]directory:: 121 The list you get with "ls" :-) 122 123[[def_dirty]]dirty:: 124 A <<def_working_tree,working tree>> is said to be "dirty" if 125 it contains modifications which have not been <<def_commit,committed>> to the current 126 <<def_branch,branch>>. 127 128[[def_evil_merge]]evil merge:: 129 An evil merge is a <<def_merge,merge>> that introduces changes that 130 do not appear in any <<def_parent,parent>>. 131 132[[def_fast_forward]]fast-forward:: 133 A fast-forward is a special type of <<def_merge,merge>> where you have a 134 <<def_revision,revision>> and you are "merging" another 135 <<def_branch,branch>>'s changes that happen to be a descendant of what 136 you have. In such these cases, you do not make a new <<def_merge,merge>> 137 <<def_commit,commit>> but instead just update to his 138 revision. This will happen frequently on a 139 <<def_remote_tracking_branch,remote-tracking branch>> of a remote 140 <<def_repository,repository>>. 141 142[[def_fetch]]fetch:: 143 Fetching a <<def_branch,branch>> means to get the 144 branch's <<def_head_ref,head ref>> from a remote 145 <<def_repository,repository>>, to find out which objects are 146 missing from the local <<def_object_database,object database>>, 147 and to get them, too. See also linkgit:git-fetch[1]. 148 149[[def_file_system]]file system:: 150 Linus Torvalds originally designed Git to be a user space file system, 151 i.e. the infrastructure to hold files and directories. That ensured the 152 efficiency and speed of Git. 153 154[[def_git_archive]]Git archive:: 155 Synonym for <<def_repository,repository>> (for arch people). 156 157[[def_gitfile]]gitfile:: 158 A plain file `.git` at the root of a working tree that 159 points at the directory that is the real repository. 160 161[[def_grafts]]grafts:: 162 Grafts enables two otherwise different lines of development to be joined 163 together by recording fake ancestry information for commits. This way 164 you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has 165 is different from what was recorded when the commit was 166 created. Configured via the `.git/info/grafts` file. 167 168[[def_hash]]hash:: 169 In Git's context, synonym for <<def_object_name,object name>>. 170 171[[def_head]]head:: 172 A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a 173 <<def_branch,branch>>. Heads are stored in a file in 174 `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See 175 linkgit:git-pack-refs[1].) 176 177[[def_HEAD]]HEAD:: 178 The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, 179 working tree>> is normally derived from the state of the tree 180 referred to by HEAD. HEAD is a reference to one of the 181 <<def_head,heads>> in your repository, except when using a 182 <<def_detached_HEAD,detached HEAD>>, in which case it directly 183 references an arbitrary commit. 184 185[[def_head_ref]]head ref:: 186 A synonym for <<def_head,head>>. 187 188[[def_hook]]hook:: 189 During the normal execution of several Git commands, call-outs are made 190 to optional scripts that allow a developer to add functionality or 191 checking. Typically, the hooks allow for a command to be pre-verified 192 and potentially aborted, and allow for a post-notification after the 193 operation is done. The hook scripts are found in the 194 `$GIT_DIR/hooks/` directory, and are enabled by simply 195 removing the `.sample` suffix from the filename. In earlier versions 196 of Git you had to make them executable. 197 198[[def_index]]index:: 199 A collection of files with stat information, whose contents are stored 200 as objects. The index is a stored version of your 201 <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even 202 a third version of a working tree, which are used 203 when <<def_merge,merging>>. 204 205[[def_index_entry]]index entry:: 206 The information regarding a particular file, stored in the 207 <<def_index,index>>. An index entry can be unmerged, if a 208 <<def_merge,merge>> was started, but not yet finished (i.e. if 209 the index contains multiple versions of that file). 210 211[[def_master]]master:: 212 The default development <<def_branch,branch>>. Whenever you 213 create a Git <<def_repository,repository>>, a branch named 214 "master" is created, and becomes the active branch. In most 215 cases, this contains the local development, though that is 216 purely by convention and is not required. 217 218[[def_merge]]merge:: 219 As a verb: To bring the contents of another 220 <<def_branch,branch>> (possibly from an external 221 <<def_repository,repository>>) into the current branch. In the 222 case where the merged-in branch is from a different repository, 223 this is done by first <<def_fetch,fetching>> the remote branch 224 and then merging the result into the current branch. This 225 combination of fetch and merge operations is called a 226 <<def_pull,pull>>. Merging is performed by an automatic process 227 that identifies changes made since the branches diverged, and 228 then applies all those changes together. In cases where changes 229 conflict, manual intervention may be required to complete the 230 merge. 231+ 232As a noun: unless it is a <<def_fast_forward,fast-forward>>, a 233successful merge results in the creation of a new <<def_commit,commit>> 234representing the result of the merge, and having as 235<<def_parent,parents>> the tips of the merged <<def_branch,branches>>. 236This commit is referred to as a "merge commit", or sometimes just a 237"merge". 238 239[[def_object]]object:: 240 The unit of storage in Git. It is uniquely identified by the 241 <<def_SHA1,SHA-1>> of its contents. Consequently, an 242 object can not be changed. 243 244[[def_object_database]]object database:: 245 Stores a set of "objects", and an individual <<def_object,object>> is 246 identified by its <<def_object_name,object name>>. The objects usually 247 live in `$GIT_DIR/objects/`. 248 249[[def_object_identifier]]object identifier:: 250 Synonym for <<def_object_name,object name>>. 251 252[[def_object_name]]object name:: 253 The unique identifier of an <<def_object,object>>. The 254 object name is usually represented by a 40 character 255 hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>. 256 257[[def_object_type]]object type:: 258 One of the identifiers "<<def_commit_object,commit>>", 259 "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or 260 "<<def_blob_object,blob>>" describing the type of an 261 <<def_object,object>>. 262 263[[def_octopus]]octopus:: 264 To <<def_merge,merge>> more than two <<def_branch,branches>>. 265 266[[def_origin]]origin:: 267 The default upstream <<def_repository,repository>>. Most projects have 268 at least one upstream project which they track. By default 269 'origin' is used for that purpose. New upstream updates 270 will be fetched into remote <<def_remote_tracking_branch,remote-tracking branches>> named 271 origin/name-of-upstream-branch, which you can see using 272 `git branch -r`. 273 274[[def_pack]]pack:: 275 A set of objects which have been compressed into one file (to save space 276 or to transmit them efficiently). 277 278[[def_pack_index]]pack index:: 279 The list of identifiers, and other information, of the objects in a 280 <<def_pack,pack>>, to assist in efficiently accessing the contents of a 281 pack. 282 283[[def_pathspec]]pathspec:: 284 Pattern used to limit paths in Git commands. 285+ 286Pathspecs are used on the command line of "git ls-files", "git 287ls-tree", "git add", "git grep", "git diff", "git checkout", 288and many other commands to 289limit the scope of operations to some subset of the tree or 290worktree. See the documentation of each command for whether 291paths are relative to the current directory or toplevel. The 292pathspec syntax is as follows: 293+ 294-- 295 296* any path matches itself 297* the pathspec up to the last slash represents a 298 directory prefix. The scope of that pathspec is 299 limited to that subtree. 300* the rest of the pathspec is a pattern for the remainder 301 of the pathname. Paths relative to the directory 302 prefix will be matched against that pattern using fnmatch(3); 303 in particular, '*' and '?' _can_ match directory separators. 304 305-- 306+ 307For example, Documentation/*.jpg will match all .jpg files 308in the Documentation subtree, 309including Documentation/chapter_1/figure_1.jpg. 310+ 311A pathspec that begins with a colon `:` has special meaning. In the 312short form, the leading colon `:` is followed by zero or more "magic 313signature" letters (which optionally is terminated by another colon `:`), 314and the remainder is the pattern to match against the path. The optional 315colon that terminates the "magic signature" can be omitted if the pattern 316begins with a character that cannot be a "magic signature" and is not a 317colon. 318+ 319In the long form, the leading colon `:` is followed by a open 320parenthesis `(`, a comma-separated list of zero or more "magic words", 321and a close parentheses `)`, and the remainder is the pattern to match 322against the path. 323+ 324The "magic signature" consists of an ASCII symbol that is not 325alphanumeric. Currently only the slash `/` is recognized as a 326"magic signature": it makes the pattern match from the root of 327the working tree, even when you are running the command from 328inside a subdirectory. 329+ 330A pathspec with only a colon means "there is no pathspec". This form 331should not be combined with other pathspec. 332 333[[def_parent]]parent:: 334 A <<def_commit_object,commit object>> contains a (possibly empty) list 335 of the logical predecessor(s) in the line of development, i.e. its 336 parents. 337 338[[def_pickaxe]]pickaxe:: 339 The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore 340 routines that help select changes that add or delete a given text 341 string. With the `--pickaxe-all` option, it can be used to view the full 342 <<def_changeset,changeset>> that introduced or removed, say, a 343 particular line of text. See linkgit:git-diff[1]. 344 345[[def_plumbing]]plumbing:: 346 Cute name for <<def_core_git,core Git>>. 347 348[[def_porcelain]]porcelain:: 349 Cute name for programs and program suites depending on 350 <<def_core_git,core Git>>, presenting a high level access to 351 core Git. Porcelains expose more of a <<def_SCM,SCM>> 352 interface than the <<def_plumbing,plumbing>>. 353 354[[def_pull]]pull:: 355 Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and 356 <<def_merge,merge>> it. See also linkgit:git-pull[1]. 357 358[[def_push]]push:: 359 Pushing a <<def_branch,branch>> means to get the branch's 360 <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, 361 find out if it is a direct ancestor to the branch's local 362 head ref, and in that case, putting all 363 objects, which are <<def_reachable,reachable>> from the local 364 head ref, and which are missing from the remote 365 repository, into the remote 366 <<def_object_database,object database>>, and updating the remote 367 head ref. If the remote <<def_head,head>> is not an 368 ancestor to the local head, the push fails. 369 370[[def_reachable]]reachable:: 371 All of the ancestors of a given <<def_commit,commit>> are said to be 372 "reachable" from that commit. More 373 generally, one <<def_object,object>> is reachable from 374 another if we can reach the one from the other by a <<def_chain,chain>> 375 that follows <<def_tag,tags>> to whatever they tag, 376 <<def_commit_object,commits>> to their parents or trees, and 377 <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> 378 that they contain. 379 380[[def_rebase]]rebase:: 381 To reapply a series of changes from a <<def_branch,branch>> to a 382 different base, and reset the <<def_head,head>> of that branch 383 to the result. 384 385[[def_ref]]ref:: 386 A 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that 387 denotes a particular <<def_object,object>>. They may be stored in 388 a file under `$GIT_DIR/refs/` directory, or 389 in the `$GIT_DIR/packed-refs` file. 390 391[[def_reflog]]reflog:: 392 A reflog shows the local "history" of a ref. In other words, 393 it can tell you what the 3rd last revision in _this_ repository 394 was, and what was the current state in _this_ repository, 395 yesterday 9:14pm. See linkgit:git-reflog[1] for details. 396 397[[def_refspec]]refspec:: 398 A "refspec" is used by <<def_fetch,fetch>> and 399 <<def_push,push>> to describe the mapping between remote 400 <<def_ref,ref>> and local ref. 401 402[[def_remote_tracking_branch]]remote-tracking branch:: 403 A regular Git <<def_branch,branch>> that is used to follow changes from 404 another <<def_repository,repository>>. A remote-tracking 405 branch should not contain direct modifications or have local commits 406 made to it. A remote-tracking branch can usually be 407 identified as the right-hand-side <<def_ref,ref>> in a Pull: 408 <<def_refspec,refspec>>. 409 410[[def_repository]]repository:: 411 A collection of <<def_ref,refs>> together with an 412 <<def_object_database,object database>> containing all objects 413 which are <<def_reachable,reachable>> from the refs, possibly 414 accompanied by meta data from one or more <<def_porcelain,porcelains>>. A 415 repository can share an object database with other repositories 416 via <<def_alternate_object_database,alternates mechanism>>. 417 418[[def_resolve]]resolve:: 419 The action of fixing up manually what a failed automatic 420 <<def_merge,merge>> left behind. 421 422[[def_revision]]revision:: 423 Synonym for <<def_commit,commit>> (the noun). 424 425[[def_rewind]]rewind:: 426 To throw away part of the development, i.e. to assign the 427 <<def_head,head>> to an earlier <<def_revision,revision>>. 428 429[[def_SCM]]SCM:: 430 Source code management (tool). 431 432[[def_SHA1]]SHA-1:: 433 "Secure Hash Algorithm 1"; a cryptographic hash function. 434 In the context of Git used as a synonym for <<def_object_name,object name>>. 435 436[[def_shallow_repository]]shallow repository:: 437 A shallow <<def_repository,repository>> has an incomplete 438 history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other 439 words, Git is told to pretend that these commits do not have the 440 parents, even though they are recorded in the <<def_commit_object,commit 441 object>>). This is sometimes useful when you are interested only in the 442 recent history of a project even though the real history recorded in the 443 upstream is much larger. A shallow repository 444 is created by giving the `--depth` option to linkgit:git-clone[1], and 445 its history can be later deepened with linkgit:git-fetch[1]. 446 447[[def_symref]]symref:: 448 Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> 449 id itself, it is of the format 'ref: refs/some/thing' and when 450 referenced, it recursively dereferences to this reference. 451 '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic 452 references are manipulated with the linkgit:git-symbolic-ref[1] 453 command. 454 455[[def_tag]]tag:: 456 A <<def_ref,ref>> under `refs/tags/` namespace that points to an 457 object of an arbitrary type (typically a tag points to either a 458 <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). 459 In contrast to a <<def_head,head>>, a tag is not updated by 460 the `commit` command. A Git tag has nothing to do with a Lisp 461 tag (which would be called an <<def_object_type,object type>> 462 in Git's context). A tag is most typically used to mark a particular 463 point in the commit ancestry <<def_chain,chain>>. 464 465[[def_tag_object]]tag object:: 466 An <<def_object,object>> containing a <<def_ref,ref>> pointing to 467 another object, which can contain a message just like a 468 <<def_commit_object,commit object>>. It can also contain a (PGP) 469 signature, in which case it is called a "signed tag object". 470 471[[def_topic_branch]]topic branch:: 472 A regular Git <<def_branch,branch>> that is used by a developer to 473 identify a conceptual line of development. Since branches are very easy 474 and inexpensive, it is often desirable to have several small branches 475 that each contain very well defined concepts or small incremental yet 476 related changes. 477 478[[def_tree]]tree:: 479 Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree 480 object>> together with the dependent <<def_blob_object,blob>> and tree objects 481 (i.e. a stored representation of a working tree). 482 483[[def_tree_object]]tree object:: 484 An <<def_object,object>> containing a list of file names and modes along 485 with refs to the associated blob and/or tree objects. A 486 <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. 487 488[[def_tree-ish]]tree-ish:: 489 A <<def_ref,ref>> pointing to either a <<def_commit_object,commit 490 object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag 491 object>> pointing to a tag or commit or tree object. 492 493[[def_unmerged_index]]unmerged index:: 494 An <<def_index,index>> which contains unmerged 495 <<def_index_entry,index entries>>. 496 497[[def_unreachable_object]]unreachable object:: 498 An <<def_object,object>> which is not <<def_reachable,reachable>> from a 499 <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. 500 501[[def_upstream_branch]]upstream branch:: 502 The default <<def_branch,branch>> that is merged into the branch in 503 question (or the branch in question is rebased onto). It is configured 504 via branch.<name>.remote and branch.<name>.merge. If the upstream branch 505 of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". 506 507[[def_working_tree]]working tree:: 508 The tree of actual checked out files. The working tree normally 509 contains the contents of the <<def_HEAD,HEAD>> commit's tree, 510 plus any local changes that you have made but not yet committed.