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 <<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. 326+ 327-- 328top `/`;; 329 The magic word `top` (mnemonic: `/`) makes the pattern match 330 from the root of the working tree, even when you are running 331 the command from inside a subdirectory. 332 333literal;; 334 Wildcards in the pattern such as `*` or `?` are treated 335 as literal characters. 336 337icase;; 338 Case insensitive match. 339 340glob;; 341 Git treats the pattern as a shell glob suitable for 342 consumption by fnmatch(3) with the FNM_PATHNAME flag: 343 wildcards in the pattern will not match a / in the pathname. 344 For example, "Documentation/{asterisk}.html" matches 345 "Documentation/git.html" but not "Documentation/ppc/ppc.html" 346 or "tools/perf/Documentation/perf.html". 347+ 348Two consecutive asterisks ("`**`") in patterns matched against 349full pathname may have special meaning: 350 351 - A leading "`**`" followed by a slash means match in all 352 directories. For example, "`**/foo`" matches file or directory 353 "`foo`" anywhere, the same as pattern "`foo`". "**/foo/bar" 354 matches file or directory "`bar`" anywhere that is directly 355 under directory "`foo`". 356 357 - A trailing "/**" matches everything inside. For example, 358 "abc/**" matches all files inside directory "abc", relative 359 to the location of the `.gitignore` file, with infinite depth. 360 361 - A slash followed by two consecutive asterisks then a slash 362 matches zero or more directories. For example, "`a/**/b`" 363 matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. 364 365 - Other consecutive asterisks are considered invalid. 366+ 367Glob magic is incompatible with literal magic. 368-- 369+ 370Currently only the slash `/` is recognized as the "magic signature", 371but it is envisioned that we will support more types of magic in later 372versions of Git. 373+ 374A pathspec with only a colon means "there is no pathspec". This form 375should not be combined with other pathspec. 376 377[[def_parent]]parent:: 378 A <<def_commit_object,commit object>> contains a (possibly empty) list 379 of the logical predecessor(s) in the line of development, i.e. its 380 parents. 381 382[[def_pickaxe]]pickaxe:: 383 The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore 384 routines that help select changes that add or delete a given text 385 string. With the `--pickaxe-all` option, it can be used to view the full 386 <<def_changeset,changeset>> that introduced or removed, say, a 387 particular line of text. See linkgit:git-diff[1]. 388 389[[def_plumbing]]plumbing:: 390 Cute name for <<def_core_git,core Git>>. 391 392[[def_porcelain]]porcelain:: 393 Cute name for programs and program suites depending on 394 <<def_core_git,core Git>>, presenting a high level access to 395 core Git. Porcelains expose more of a <<def_SCM,SCM>> 396 interface than the <<def_plumbing,plumbing>>. 397 398[[def_pull]]pull:: 399 Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and 400 <<def_merge,merge>> it. See also linkgit:git-pull[1]. 401 402[[def_push]]push:: 403 Pushing a <<def_branch,branch>> means to get the branch's 404 <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, 405 find out if it is a direct ancestor to the branch's local 406 head ref, and in that case, putting all 407 objects, which are <<def_reachable,reachable>> from the local 408 head ref, and which are missing from the remote 409 repository, into the remote 410 <<def_object_database,object database>>, and updating the remote 411 head ref. If the remote <<def_head,head>> is not an 412 ancestor to the local head, the push fails. 413 414[[def_reachable]]reachable:: 415 All of the ancestors of a given <<def_commit,commit>> are said to be 416 "reachable" from that commit. More 417 generally, one <<def_object,object>> is reachable from 418 another if we can reach the one from the other by a <<def_chain,chain>> 419 that follows <<def_tag,tags>> to whatever they tag, 420 <<def_commit_object,commits>> to their parents or trees, and 421 <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> 422 that they contain. 423 424[[def_rebase]]rebase:: 425 To reapply a series of changes from a <<def_branch,branch>> to a 426 different base, and reset the <<def_head,head>> of that branch 427 to the result. 428 429[[def_ref]]ref:: 430 A 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that 431 denotes a particular <<def_object,object>>. They may be stored in 432 a file under `$GIT_DIR/refs/` directory, or 433 in the `$GIT_DIR/packed-refs` file. 434 435[[def_reflog]]reflog:: 436 A reflog shows the local "history" of a ref. In other words, 437 it can tell you what the 3rd last revision in _this_ repository 438 was, and what was the current state in _this_ repository, 439 yesterday 9:14pm. See linkgit:git-reflog[1] for details. 440 441[[def_refspec]]refspec:: 442 A "refspec" is used by <<def_fetch,fetch>> and 443 <<def_push,push>> to describe the mapping between remote 444 <<def_ref,ref>> and local ref. 445 446[[def_remote_tracking_branch]]remote-tracking branch:: 447 A <<def_ref,ref>> that is used to follow changes from another 448 <<def_repository,repository>>. It typically looks like 449 'refs/remotes/foo/bar' (indicating that it tracks a branch named 450 'bar' in a remote named 'foo'), and matches the right-hand-side of 451 a configured fetch <<def_refspec,refspec>>. A remote-tracking 452 branch should not contain direct modifications or have local 453 commits made to it. 454 455[[def_repository]]repository:: 456 A collection of <<def_ref,refs>> together with an 457 <<def_object_database,object database>> containing all objects 458 which are <<def_reachable,reachable>> from the refs, possibly 459 accompanied by meta data from one or more <<def_porcelain,porcelains>>. A 460 repository can share an object database with other repositories 461 via <<def_alternate_object_database,alternates mechanism>>. 462 463[[def_resolve]]resolve:: 464 The action of fixing up manually what a failed automatic 465 <<def_merge,merge>> left behind. 466 467[[def_revision]]revision:: 468 Synonym for <<def_commit,commit>> (the noun). 469 470[[def_rewind]]rewind:: 471 To throw away part of the development, i.e. to assign the 472 <<def_head,head>> to an earlier <<def_revision,revision>>. 473 474[[def_SCM]]SCM:: 475 Source code management (tool). 476 477[[def_SHA1]]SHA-1:: 478 "Secure Hash Algorithm 1"; a cryptographic hash function. 479 In the context of Git used as a synonym for <<def_object_name,object name>>. 480 481[[def_shallow_repository]]shallow repository:: 482 A shallow <<def_repository,repository>> has an incomplete 483 history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other 484 words, Git is told to pretend that these commits do not have the 485 parents, even though they are recorded in the <<def_commit_object,commit 486 object>>). This is sometimes useful when you are interested only in the 487 recent history of a project even though the real history recorded in the 488 upstream is much larger. A shallow repository 489 is created by giving the `--depth` option to linkgit:git-clone[1], and 490 its history can be later deepened with linkgit:git-fetch[1]. 491 492[[def_symref]]symref:: 493 Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> 494 id itself, it is of the format 'ref: refs/some/thing' and when 495 referenced, it recursively dereferences to this reference. 496 '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic 497 references are manipulated with the linkgit:git-symbolic-ref[1] 498 command. 499 500[[def_tag]]tag:: 501 A <<def_ref,ref>> under `refs/tags/` namespace that points to an 502 object of an arbitrary type (typically a tag points to either a 503 <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). 504 In contrast to a <<def_head,head>>, a tag is not updated by 505 the `commit` command. A Git tag has nothing to do with a Lisp 506 tag (which would be called an <<def_object_type,object type>> 507 in Git's context). A tag is most typically used to mark a particular 508 point in the commit ancestry <<def_chain,chain>>. 509 510[[def_tag_object]]tag object:: 511 An <<def_object,object>> containing a <<def_ref,ref>> pointing to 512 another object, which can contain a message just like a 513 <<def_commit_object,commit object>>. It can also contain a (PGP) 514 signature, in which case it is called a "signed tag object". 515 516[[def_topic_branch]]topic branch:: 517 A regular Git <<def_branch,branch>> that is used by a developer to 518 identify a conceptual line of development. Since branches are very easy 519 and inexpensive, it is often desirable to have several small branches 520 that each contain very well defined concepts or small incremental yet 521 related changes. 522 523[[def_tree]]tree:: 524 Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree 525 object>> together with the dependent <<def_blob_object,blob>> and tree objects 526 (i.e. a stored representation of a working tree). 527 528[[def_tree_object]]tree object:: 529 An <<def_object,object>> containing a list of file names and modes along 530 with refs to the associated blob and/or tree objects. A 531 <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. 532 533[[def_tree-ish]]tree-ish:: 534 A <<def_ref,ref>> pointing to either a <<def_commit_object,commit 535 object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag 536 object>> pointing to a tag or commit or tree object. 537 538[[def_unmerged_index]]unmerged index:: 539 An <<def_index,index>> which contains unmerged 540 <<def_index_entry,index entries>>. 541 542[[def_unreachable_object]]unreachable object:: 543 An <<def_object,object>> which is not <<def_reachable,reachable>> from a 544 <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. 545 546[[def_upstream_branch]]upstream branch:: 547 The default <<def_branch,branch>> that is merged into the branch in 548 question (or the branch in question is rebased onto). It is configured 549 via branch.<name>.remote and branch.<name>.merge. If the upstream branch 550 of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". 551 552[[def_working_tree]]working tree:: 553 The tree of actual checked out files. The working tree normally 554 contains the contents of the <<def_HEAD,HEAD>> commit's tree, 555 plus any local changes that you have made but not yet committed.