diff options
Diffstat (limited to 'Documentation/glossary-content.txt')
| -rw-r--r-- | Documentation/glossary-content.txt | 724 |
1 files changed, 724 insertions, 0 deletions
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt new file mode 100644 index 0000000..59d8ab8 --- /dev/null +++ b/Documentation/glossary-content.txt @@ -0,0 +1,724 @@ +[[def_alternate_object_database]]alternate object database:: + Via the alternates mechanism, a <<def_repository,repository>> + can inherit part of its <<def_object_database,object database>> + from another object database, which is called an "alternate". + +[[def_bare_repository]]bare repository:: + A bare repository is normally an appropriately + named <<def_directory,directory>> with a `.git` suffix that does not + have a locally checked-out copy of any of the files under + revision control. That is, all of the Git + administrative and control files that would normally be present in the + hidden `.git` sub-directory are directly present in the + `repository.git` directory instead, + and no other files are present and checked out. Usually publishers of + public repositories make bare repositories available. + +[[def_blob_object]]blob object:: + Untyped <<def_object,object>>, e.g. the contents of a file. + +[[def_branch]]branch:: + A "branch" is a line of development. The most recent + <<def_commit,commit>> on a branch is referred to as the tip of + that branch. The tip of the branch is <<def_ref,referenced>> by a branch + <<def_head,head>>, which moves forward as additional development + is done on the branch. A single Git + <<def_repository,repository>> can track an arbitrary number of + branches, but your <<def_working_tree,working tree>> is + associated with just one of them (the "current" or "checked out" + branch), and <<def_HEAD,HEAD>> points to that branch. + +[[def_cache]]cache:: + Obsolete for: <<def_index,index>>. + +[[def_chain]]chain:: + A list of objects, where each <<def_object,object>> in the list contains + a reference to its successor (for example, the successor of a + <<def_commit,commit>> could be one of its <<def_parent,parents>>). + +[[def_changeset]]changeset:: + BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not + store changes, but states, it really does not make sense to use the term + "changesets" with Git. + +[[def_checkout]]checkout:: + The action of updating all or part of the + <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> + or <<def_blob_object,blob>> from the + <<def_object_database,object database>>, and updating the + <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has + been pointed at a new <<def_branch,branch>>. + +[[def_cherry-picking]]cherry-picking:: + In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of + changes out of a series of changes (typically commits) and record them + as a new series of changes on top of a different codebase. In Git, this is + performed by the "git cherry-pick" command to extract the change introduced + by an existing <<def_commit,commit>> and to record it based on the tip + of the current <<def_branch,branch>> as a new commit. + +[[def_clean]]clean:: + A <<def_working_tree,working tree>> is clean, if it + corresponds to the <<def_revision,revision>> referenced by the current + <<def_head,head>>. Also see "<<def_dirty,dirty>>". + +[[def_commit]]commit:: + As a noun: A single point in the + Git history; the entire history of a project is represented as a + set of interrelated commits. The word "commit" is often + used by Git in the same places other revision control systems + use the words "revision" or "version". Also used as a short + hand for <<def_commit_object,commit object>>. ++ +As a verb: The action of storing a new snapshot of the project's +state in the Git history, by creating a new commit representing the current +state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> +to point at the new commit. + +[[def_commit_graph_general]]commit graph concept, representations and usage:: + A synonym for the <<def_DAG,DAG>> structure formed by the commits + in the object database, <<def_ref,referenced>> by branch tips, + using their <<def_chain,chain>> of linked commits. + This structure is the definitive commit graph. The + graph can be represented in other ways, e.g. the + <<def_commit_graph_file,"commit-graph" file>>. + +[[def_commit_graph_file]]commit-graph file:: + The "commit-graph" (normally hyphenated) file is a supplemental + representation of the <<def_commit_graph_general,commit graph>> + which accelerates commit graph walks. The "commit-graph" file is + stored either in the .git/objects/info directory or in the info + directory of an alternate object database. + +[[def_commit_object]]commit object:: + An <<def_object,object>> which contains the information about a + particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, + author, date and the <<def_tree_object,tree object>> which corresponds + to the top <<def_directory,directory>> of the stored + revision. + +[[def_commit-ish]]commit-ish (also committish):: + A <<def_commit_object,commit object>> or an <<def_object,object>> that + can be recursively <<def_dereference,dereferenced>> to a commit object. + The following are all commit-ishes: + a commit object, + a <<def_tag_object,tag object>> that points to a commit + object, + a tag object that points to a tag object that points to a + commit object, + etc. + +[[def_core_git]]core Git:: + Fundamental data structures and utilities of Git. Exposes only limited + source code management tools. + +[[def_DAG]]DAG:: + Directed acyclic graph. The <<def_commit_object,commit objects>> form a + directed acyclic graph, because they have parents (directed), and the + graph of commit objects is acyclic (there is no <<def_chain,chain>> + which begins and ends with the same <<def_object,object>>). + +[[def_dangling_object]]dangling object:: + An <<def_unreachable_object,unreachable object>> which is not + <<def_reachable,reachable>> even from other unreachable objects; a + dangling object has no references to it from any + reference or <<def_object,object>> in the <<def_repository,repository>>. + +[[def_dereference]]dereference:: + Referring to a <<def_symref,symbolic ref>>: the action of accessing the + <<def_ref,reference>> pointed at by a symbolic ref. Recursive + dereferencing involves repeating the aforementioned process on the + resulting ref until a non-symbolic reference is found. ++ +Referring to a <<def_tag_object,tag object>>: the action of accessing the +<<def_object,object>> a tag points at. Tags are recursively dereferenced by +repeating the operation on the result object until the result has either a +specified <<def_object_type,object type>> (where applicable) or any non-"tag" +object type. A synonym for "recursive dereference" in the context of tags is +"<<def_peel,peel>>". ++ +Referring to a <<def_commit_object,commit object>>: the action of accessing +the commit's tree object. Commits cannot be dereferenced recursively. ++ +Unless otherwise specified, "dereferencing" as it used in the context of Git +commands or protocols is implicitly recursive. + +[[def_detached_HEAD]]detached HEAD:: + Normally the <<def_HEAD,HEAD>> stores the name of a + <<def_branch,branch>>, and commands that operate on the + history HEAD represents operate on the history leading to the + tip of the branch the HEAD points at. However, Git also + allows you to <<def_checkout,check out>> an arbitrary + <<def_commit,commit>> that isn't necessarily the tip of any + particular branch. The HEAD in such a state is called + "detached". ++ +Note that commands that operate on the history of the current branch +(e.g. `git commit` to build a new history on top of it) still work +while the HEAD is detached. They update the HEAD to point at the tip +of the updated history without affecting any branch. Commands that +update or inquire information _about_ the current branch (e.g. `git +branch --set-upstream-to` that sets what remote-tracking branch the +current branch integrates with) obviously do not work, as there is no +(real) current branch to ask about in this state. + +[[def_directory]]directory:: + The list you get with "ls" :-) + +[[def_dirty]]dirty:: + A <<def_working_tree,working tree>> is said to be "dirty" if + it contains modifications which have not been <<def_commit,committed>> to the current + <<def_branch,branch>>. + +[[def_evil_merge]]evil merge:: + An evil merge is a <<def_merge,merge>> that introduces changes that + do not appear in any <<def_parent,parent>>. + +[[def_fast_forward]]fast-forward:: + A fast-forward is a special type of <<def_merge,merge>> where you have a + <<def_revision,revision>> and you are "merging" another + <<def_branch,branch>>'s changes that happen to be a descendant of what + you have. In such a case, you do not make a new <<def_merge,merge>> + <<def_commit,commit>> but instead just update your branch to point at the same + revision as the branch you are merging. This will happen frequently on a + <<def_remote_tracking_branch,remote-tracking branch>> of a remote + <<def_repository,repository>>. + +[[def_fetch]]fetch:: + Fetching a <<def_branch,branch>> means to get the + branch's <<def_head_ref,head ref>> from a remote + <<def_repository,repository>>, to find out which objects are + missing from the local <<def_object_database,object database>>, + and to get them, too. See also linkgit:git-fetch[1]. + +[[def_file_system]]file system:: + Linus Torvalds originally designed Git to be a user space file system, + i.e. the infrastructure to hold files and directories. That ensured the + efficiency and speed of Git. + +[[def_git_archive]]Git archive:: + Synonym for <<def_repository,repository>> (for arch people). + +[[def_gitfile]]gitfile:: + A plain file `.git` at the root of a working tree that + points at the directory that is the real repository. + +[[def_grafts]]grafts:: + Grafts enable two otherwise different lines of development to be joined + together by recording fake ancestry information for commits. This way + you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has + is different from what was recorded when the commit was + created. Configured via the `.git/info/grafts` file. ++ +Note that the grafts mechanism is outdated and can lead to problems +transferring objects between repositories; see linkgit:git-replace[1] +for a more flexible and robust system to do the same thing. + +[[def_hash]]hash:: + In Git's context, synonym for <<def_object_name,object name>>. + +[[def_head]]head:: + A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a + <<def_branch,branch>>. Heads are stored in a file in + `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See + linkgit:git-pack-refs[1].) + +[[def_HEAD]]HEAD:: + The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, + working tree>> is normally derived from the state of the tree + referred to by HEAD. HEAD is a reference to one of the + <<def_head,heads>> in your repository, except when using a + <<def_detached_HEAD,detached HEAD>>, in which case it directly + references an arbitrary commit. + +[[def_head_ref]]head ref:: + A synonym for <<def_head,head>>. + +[[def_hook]]hook:: + During the normal execution of several Git commands, call-outs are made + to optional scripts that allow a developer to add functionality or + checking. Typically, the hooks allow for a command to be pre-verified + and potentially aborted, and allow for a post-notification after the + operation is done. The hook scripts are found in the + `$GIT_DIR/hooks/` directory, and are enabled by simply + removing the `.sample` suffix from the filename. In earlier versions + of Git you had to make them executable. + +[[def_index]]index:: + A collection of files with stat information, whose contents are stored + as objects. The index is a stored version of your + <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even + a third version of a working tree, which are used + when <<def_merge,merging>>. + +[[def_index_entry]]index entry:: + The information regarding a particular file, stored in the + <<def_index,index>>. An index entry can be unmerged, if a + <<def_merge,merge>> was started, but not yet finished (i.e. if + the index contains multiple versions of that file). + +[[def_master]]master:: + The default development <<def_branch,branch>>. Whenever you + create a Git <<def_repository,repository>>, a branch named + "master" is created, and becomes the active branch. In most + cases, this contains the local development, though that is + purely by convention and is not required. + +[[def_merge]]merge:: + As a verb: To bring the contents of another + <<def_branch,branch>> (possibly from an external + <<def_repository,repository>>) into the current branch. In the + case where the merged-in branch is from a different repository, + this is done by first <<def_fetch,fetching>> the remote branch + and then merging the result into the current branch. This + combination of fetch and merge operations is called a + <<def_pull,pull>>. Merging is performed by an automatic process + that identifies changes made since the branches diverged, and + then applies all those changes together. In cases where changes + conflict, manual intervention may be required to complete the + merge. ++ +As a noun: unless it is a <<def_fast_forward,fast-forward>>, a +successful merge results in the creation of a new <<def_commit,commit>> +representing the result of the merge, and having as +<<def_parent,parents>> the tips of the merged <<def_branch,branches>>. +This commit is referred to as a "merge commit", or sometimes just a +"merge". + +[[def_object]]object:: + The unit of storage in Git. It is uniquely identified by the + <<def_SHA1,SHA-1>> of its contents. Consequently, an + object cannot be changed. + +[[def_object_database]]object database:: + Stores a set of "objects", and an individual <<def_object,object>> is + identified by its <<def_object_name,object name>>. The objects usually + live in `$GIT_DIR/objects/`. + +[[def_object_identifier]]object identifier (oid):: + Synonym for <<def_object_name,object name>>. + +[[def_object_name]]object name:: + The unique identifier of an <<def_object,object>>. The + object name is usually represented by a 40 character + hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>. + +[[def_object_type]]object type:: + One of the identifiers "<<def_commit_object,commit>>", + "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or + "<<def_blob_object,blob>>" describing the type of an + <<def_object,object>>. + +[[def_octopus]]octopus:: + To <<def_merge,merge>> more than two <<def_branch,branches>>. + +[[def_origin]]origin:: + The default upstream <<def_repository,repository>>. Most projects have + at least one upstream project which they track. By default + 'origin' is used for that purpose. New upstream updates + will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named + origin/name-of-upstream-branch, which you can see using + `git branch -r`. + +[[def_overlay]]overlay:: + Only update and add files to the working directory, but don't + delete them, similar to how 'cp -R' would update the contents + in the destination directory. This is the default mode in a + <<def_checkout,checkout>> when checking out files from the + <<def_index,index>> or a <<def_tree-ish,tree-ish>>. In + contrast, no-overlay mode also deletes tracked files not + present in the source, similar to 'rsync --delete'. + +[[def_pack]]pack:: + A set of objects which have been compressed into one file (to save space + or to transmit them efficiently). + +[[def_pack_index]]pack index:: + The list of identifiers, and other information, of the objects in a + <<def_pack,pack>>, to assist in efficiently accessing the contents of a + pack. + +[[def_pathspec]]pathspec:: + Pattern used to limit paths in Git commands. ++ +Pathspecs are used on the command line of "git ls-files", "git +ls-tree", "git add", "git grep", "git diff", "git checkout", +and many other commands to +limit the scope of operations to some subset of the tree or +working tree. See the documentation of each command for whether +paths are relative to the current directory or toplevel. The +pathspec syntax is as follows: ++ +-- + +* any path matches itself +* the pathspec up to the last slash represents a + directory prefix. The scope of that pathspec is + limited to that subtree. +* the rest of the pathspec is a pattern for the remainder + of the pathname. Paths relative to the directory + prefix will be matched against that pattern using fnmatch(3); + in particular, '*' and '?' _can_ match directory separators. + +-- ++ +For example, Documentation/*.jpg will match all .jpg files +in the Documentation subtree, +including Documentation/chapter_1/figure_1.jpg. ++ +A pathspec that begins with a colon `:` has special meaning. In the +short form, the leading colon `:` is followed by zero or more "magic +signature" letters (which optionally is terminated by another colon `:`), +and the remainder is the pattern to match against the path. +The "magic signature" consists of ASCII symbols that are neither +alphanumeric, glob, regex special characters nor colon. +The optional colon that terminates the "magic signature" can be +omitted if the pattern begins with a character that does not belong to +"magic signature" symbol set and is not a colon. ++ +In the long form, the leading colon `:` is followed by an open +parenthesis `(`, a comma-separated list of zero or more "magic words", +and a close parentheses `)`, and the remainder is the pattern to match +against the path. ++ +A pathspec with only a colon means "there is no pathspec". This form +should not be combined with other pathspec. ++ +-- +top;; + The magic word `top` (magic signature: `/`) makes the pattern + match from the root of the working tree, even when you are + running the command from inside a subdirectory. + +literal;; + Wildcards in the pattern such as `*` or `?` are treated + as literal characters. + +icase;; + Case insensitive match. + +glob;; + Git treats the pattern as a shell glob suitable for + consumption by fnmatch(3) with the FNM_PATHNAME flag: + wildcards in the pattern will not match a / in the pathname. + For example, "Documentation/{asterisk}.html" matches + "Documentation/git.html" but not "Documentation/ppc/ppc.html" + or "tools/perf/Documentation/perf.html". ++ +Two consecutive asterisks ("`**`") in patterns matched against +full pathname may have special meaning: + + - A leading "`**`" followed by a slash means match in all + directories. For example, "`**/foo`" matches file or directory + "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" + matches file or directory "`bar`" anywhere that is directly + under directory "`foo`". + + - A trailing "`/**`" matches everything inside. For example, + "`abc/**`" matches all files inside directory "abc", relative + to the location of the `.gitignore` file, with infinite depth. + + - A slash followed by two consecutive asterisks then a slash + matches zero or more directories. For example, "`a/**/b`" + matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. + + - Other consecutive asterisks are considered invalid. ++ +Glob magic is incompatible with literal magic. + +attr;; +After `attr:` comes a space separated list of "attribute +requirements", all of which must be met in order for the +path to be considered a match; this is in addition to the +usual non-magic pathspec pattern matching. +See linkgit:gitattributes[5]. ++ +Each of the attribute requirements for the path takes one of +these forms: + +- "`ATTR`" requires that the attribute `ATTR` be set. + +- "`-ATTR`" requires that the attribute `ATTR` be unset. + +- "`ATTR=VALUE`" requires that the attribute `ATTR` be + set to the string `VALUE`. + +- "`!ATTR`" requires that the attribute `ATTR` be + unspecified. ++ +Note that when matching against a tree object, attributes are still +obtained from working tree, not from the given tree object. + +exclude;; + After a path matches any non-exclude pathspec, it will be run + through all exclude pathspecs (magic signature: `!` or its + synonym `^`). If it matches, the path is ignored. When there + is no non-exclude pathspec, the exclusion is applied to the + result set as if invoked without any pathspec. +-- + +[[def_parent]]parent:: + A <<def_commit_object,commit object>> contains a (possibly empty) list + of the logical predecessor(s) in the line of development, i.e. its + parents. + +[[def_peel]]peel:: + The action of recursively <<def_dereference,dereferencing>> a + <<def_tag_object,tag object>>. + +[[def_pickaxe]]pickaxe:: + The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore + routines that help select changes that add or delete a given text + string. With the `--pickaxe-all` option, it can be used to view the full + <<def_changeset,changeset>> that introduced or removed, say, a + particular line of text. See linkgit:git-diff[1]. + +[[def_plumbing]]plumbing:: + Cute name for <<def_core_git,core Git>>. + +[[def_porcelain]]porcelain:: + Cute name for programs and program suites depending on + <<def_core_git,core Git>>, presenting a high level access to + core Git. Porcelains expose more of a <<def_SCM,SCM>> + interface than the <<def_plumbing,plumbing>>. + +[[def_per_worktree_ref]]per-worktree ref:: + Refs that are per-<<def_worktree,worktree>>, rather than + global. This is presently only <<def_HEAD,HEAD>> and any refs + that start with `refs/bisect/`, but might later include other + unusual refs. + +[[def_pseudoref]]pseudoref:: + Pseudorefs are a class of files under `$GIT_DIR` which behave + like refs for the purposes of rev-parse, but which are treated + specially by git. Pseudorefs both have names that are all-caps, + and always start with a line consisting of a + <<def_SHA1,SHA-1>> followed by whitespace. So, HEAD is not a + pseudoref, because it is sometimes a symbolic ref. They might + optionally contain some additional data. `MERGE_HEAD` and + `CHERRY_PICK_HEAD` are examples. Unlike + <<def_per_worktree_ref,per-worktree refs>>, these files cannot + be symbolic refs, and never have reflogs. They also cannot be + updated through the normal ref update machinery. Instead, + they are updated by directly writing to the files. However, + they can be read as if they were refs, so `git rev-parse + MERGE_HEAD` will work. + +[[def_pull]]pull:: + Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and + <<def_merge,merge>> it. See also linkgit:git-pull[1]. + +[[def_push]]push:: + Pushing a <<def_branch,branch>> means to get the branch's + <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, + find out if it is an ancestor to the branch's local + head ref, and in that case, putting all + objects, which are <<def_reachable,reachable>> from the local + head ref, and which are missing from the remote + repository, into the remote + <<def_object_database,object database>>, and updating the remote + head ref. If the remote <<def_head,head>> is not an + ancestor to the local head, the push fails. + +[[def_reachable]]reachable:: + All of the ancestors of a given <<def_commit,commit>> are said to be + "reachable" from that commit. More + generally, one <<def_object,object>> is reachable from + another if we can reach the one from the other by a <<def_chain,chain>> + that follows <<def_tag,tags>> to whatever they tag, + <<def_commit_object,commits>> to their parents or trees, and + <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> + that they contain. + +[[def_reachability_bitmap]]reachability bitmaps:: + Reachability bitmaps store information about the + <<def_reachable,reachability>> of a selected set of commits in + a packfile, or a multi-pack index (MIDX), to speed up object search. + The bitmaps are stored in a ".bitmap" file. A repository may have at + most one bitmap file in use. The bitmap file may belong to either one + pack, or the repository's multi-pack index (if it exists). + +[[def_rebase]]rebase:: + To reapply a series of changes from a <<def_branch,branch>> to a + different base, and reset the <<def_head,head>> of that branch + to the result. + +[[def_ref]]ref:: + A name that begins with `refs/` (e.g. `refs/heads/master`) + that points to an <<def_object_name,object name>> or another + ref (the latter is called a <<def_symref,symbolic ref>>). + For convenience, a ref can sometimes be abbreviated when used + as an argument to a Git command; see linkgit:gitrevisions[7] + for details. + Refs are stored in the <<def_repository,repository>>. ++ +The ref namespace is hierarchical. +Different subhierarchies are used for different purposes (e.g. the +`refs/heads/` hierarchy is used to represent local branches). ++ +There are a few special-purpose refs that do not begin with `refs/`. +The most notable example is `HEAD`. + +[[def_reflog]]reflog:: + A reflog shows the local "history" of a ref. In other words, + it can tell you what the 3rd last revision in _this_ repository + was, and what was the current state in _this_ repository, + yesterday 9:14pm. See linkgit:git-reflog[1] for details. + +[[def_refspec]]refspec:: + A "refspec" is used by <<def_fetch,fetch>> and + <<def_push,push>> to describe the mapping between remote + <<def_ref,ref>> and local ref. + +[[def_remote]]remote repository:: + A <<def_repository,repository>> which is used to track the same + project but resides somewhere else. To communicate with remotes, + see <<def_fetch,fetch>> or <<def_push,push>>. + +[[def_remote_tracking_branch]]remote-tracking branch:: + A <<def_ref,ref>> that is used to follow changes from another + <<def_repository,repository>>. It typically looks like + 'refs/remotes/foo/bar' (indicating that it tracks a branch named + 'bar' in a remote named 'foo'), and matches the right-hand-side of + a configured fetch <<def_refspec,refspec>>. A remote-tracking + branch should not contain direct modifications or have local + commits made to it. + +[[def_repository]]repository:: + A collection of <<def_ref,refs>> together with an + <<def_object_database,object database>> containing all objects + which are <<def_reachable,reachable>> from the refs, possibly + accompanied by meta data from one or more <<def_porcelain,porcelains>>. A + repository can share an object database with other repositories + via <<def_alternate_object_database,alternates mechanism>>. + +[[def_resolve]]resolve:: + The action of fixing up manually what a failed automatic + <<def_merge,merge>> left behind. + +[[def_revision]]revision:: + Synonym for <<def_commit,commit>> (the noun). + +[[def_rewind]]rewind:: + To throw away part of the development, i.e. to assign the + <<def_head,head>> to an earlier <<def_revision,revision>>. + +[[def_SCM]]SCM:: + Source code management (tool). + +[[def_SHA1]]SHA-1:: + "Secure Hash Algorithm 1"; a cryptographic hash function. + In the context of Git used as a synonym for <<def_object_name,object name>>. + +[[def_shallow_clone]]shallow clone:: + Mostly a synonym to <<def_shallow_repository,shallow repository>> + but the phrase makes it more explicit that it was created by + running `git clone --depth=...` command. + +[[def_shallow_repository]]shallow repository:: + A shallow <<def_repository,repository>> has an incomplete + history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other + words, Git is told to pretend that these commits do not have the + parents, even though they are recorded in the <<def_commit_object,commit + object>>). This is sometimes useful when you are interested only in the + recent history of a project even though the real history recorded in the + upstream is much larger. A shallow repository + is created by giving the `--depth` option to linkgit:git-clone[1], and + its history can be later deepened with linkgit:git-fetch[1]. + +[[def_stash]]stash entry:: + An <<def_object,object>> used to temporarily store the contents of a + <<def_dirty,dirty>> working directory and the index for future reuse. + +[[def_submodule]]submodule:: + A <<def_repository,repository>> that holds the history of a + separate project inside another repository (the latter of + which is called <<def_superproject, superproject>>). + +[[def_superproject]]superproject:: + A <<def_repository,repository>> that references repositories + of other projects in its working tree as <<def_submodule,submodules>>. + The superproject knows about the names of (but does not hold + copies of) commit objects of the contained submodules. + +[[def_symref]]symref:: + Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> id + itself, it is of the format 'ref: refs/some/thing' and when referenced, + it recursively <<def_dereference,dereferences>> to this reference. + '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic references + are manipulated with the linkgit:git-symbolic-ref[1] command. + +[[def_tag]]tag:: + A <<def_ref,ref>> under `refs/tags/` namespace that points to an + object of an arbitrary type (typically a tag points to either a + <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). + In contrast to a <<def_head,head>>, a tag is not updated by + the `commit` command. A Git tag has nothing to do with a Lisp + tag (which would be called an <<def_object_type,object type>> + in Git's context). A tag is most typically used to mark a particular + point in the commit ancestry <<def_chain,chain>>. + +[[def_tag_object]]tag object:: + An <<def_object,object>> containing a <<def_ref,ref>> pointing to + another object, which can contain a message just like a + <<def_commit_object,commit object>>. It can also contain a (PGP) + signature, in which case it is called a "signed tag object". + +[[def_topic_branch]]topic branch:: + A regular Git <<def_branch,branch>> that is used by a developer to + identify a conceptual line of development. Since branches are very easy + and inexpensive, it is often desirable to have several small branches + that each contain very well defined concepts or small incremental yet + related changes. + +[[def_tree]]tree:: + Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree + object>> together with the dependent <<def_blob_object,blob>> and tree objects + (i.e. a stored representation of a working tree). + +[[def_tree_object]]tree object:: + An <<def_object,object>> containing a list of file names and modes along + with refs to the associated blob and/or tree objects. A + <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. + +[[def_tree-ish]]tree-ish (also treeish):: + A <<def_tree_object,tree object>> or an <<def_object,object>> that can + be recursively <<def_dereference,dereferenced>> to a tree object. + Dereferencing a <<def_commit_object,commit object>> yields the tree + object corresponding to the <<def_revision,revision>>'s top + <<def_directory,directory>>. + The following are all tree-ishes: + a <<def_commit-ish,commit-ish>>, + a tree object, + a <<def_tag_object,tag object>> that points to a tree object, + a tag object that points to a tag object that points to a tree + object, + etc. + +[[def_unmerged_index]]unmerged index:: + An <<def_index,index>> which contains unmerged + <<def_index_entry,index entries>>. + +[[def_unreachable_object]]unreachable object:: + An <<def_object,object>> which is not <<def_reachable,reachable>> from a + <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. + +[[def_upstream_branch]]upstream branch:: + The default <<def_branch,branch>> that is merged into the branch in + question (or the branch in question is rebased onto). It is configured + via branch.<name>.remote and branch.<name>.merge. If the upstream branch + of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". + +[[def_working_tree]]working tree:: + The tree of actual checked out files. The working tree normally + contains the contents of the <<def_HEAD,HEAD>> commit's tree, + plus any local changes that you have made but not yet committed. + +[[def_worktree]]worktree:: + A repository can have zero (i.e. bare repository) or one or + more worktrees attached to it. One "worktree" consists of a + "working tree" and repository metadata, most of which are + shared among other worktrees of a single repository, and + some of which are maintained separately per worktree + (e.g. the index, HEAD and pseudorefs like MERGE_HEAD, + per-worktree refs and per-worktree configuration file). |