--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>\r
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">\r
+\r
+<article lang="en" id="gitglossary(7)">\r
+<articleinfo>\r
+ <title>gitglossary(7)</title>\r
+ <indexterm>\r
+ <primary>gitglossary(7)</primary>\r
+ </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>gitglossary - A GIT Glossary</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara>*</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_alternate_object_database" xreflabel="[def_alternate_object_database]"/>alternate object database\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Via the alternates mechanism, a <link linkend="def_repository">repository</link>\r
+ can inherit part of its <link linkend="def_object_database">object database</link>\r
+ from another object database, which is called "alternate".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_bare_repository" xreflabel="[def_bare_repository]"/>bare repository\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A bare repository is normally an appropriately\r
+ named <link linkend="def_directory">directory</link> with a <literal>.git</literal> suffix that does not\r
+ have a locally checked-out copy of any of the files under\r
+ revision control. That is, all of the <literal>git</literal>\r
+ administrative and control files that would normally be present in the\r
+ hidden <literal>.git</literal> sub-directory are directly present in the\r
+ <literal>repository.git</literal> directory instead,\r
+ and no other files are present and checked out. Usually publishers of\r
+ public repositories make bare repositories available.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_blob_object" xreflabel="[def_blob_object]"/>blob object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Untyped <link linkend="def_object">object</link>, e.g. the contents of a file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_branch" xreflabel="[def_branch]"/>branch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A "branch" is an active line of development. The most recent\r
+ <link linkend="def_commit">commit</link> on a branch is referred to as the tip of\r
+ that branch. The tip of the branch is referenced by a branch\r
+ <link linkend="def_head">head</link>, which moves forward as additional development\r
+ is done on the branch. A single git\r
+ <link linkend="def_repository">repository</link> can track an arbitrary number of\r
+ branches, but your <link linkend="def_working_tree">working tree</link> is\r
+ associated with just one of them (the "current" or "checked out"\r
+ branch), and <link linkend="def_HEAD">HEAD</link> points to that branch.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_cache" xreflabel="[def_cache]"/>cache\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Obsolete for: <link linkend="def_index">index</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_chain" xreflabel="[def_chain]"/>chain\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A list of objects, where each <link linkend="def_object">object</link> in the list contains\r
+ a reference to its successor (for example, the successor of a\r
+ <link linkend="def_commit">commit</link> could be one of its <link linkend="def_parent">parents</link>).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_changeset" xreflabel="[def_changeset]"/>changeset\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ BitKeeper/cvsps speak for "<link linkend="def_commit">commit</link>". Since git does not\r
+ store changes, but states, it really does not make sense to use the term\r
+ "changesets" with git.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_checkout" xreflabel="[def_checkout]"/>checkout\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The action of updating all or part of the\r
+ <link linkend="def_working_tree">working tree</link> with a <link linkend="def_tree_object">tree object</link>\r
+ or <link linkend="def_blob_object">blob</link> from the\r
+ <link linkend="def_object_database">object database</link>, and updating the\r
+ <link linkend="def_index">index</link> and <link linkend="def_HEAD">HEAD</link> if the whole working tree has\r
+ been pointed at a new <link linkend="def_branch">branch</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_cherry-picking" xreflabel="[def_cherry-picking]"/>cherry-picking\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ In <link linkend="def_SCM">SCM</link> jargon, "cherry pick" means to choose a subset of\r
+ changes out of a series of changes (typically commits) and record them\r
+ as a new series of changes on top of a different codebase. In GIT, this is\r
+ performed by the "git cherry-pick" command to extract the change introduced\r
+ by an existing <link linkend="def_commit">commit</link> and to record it based on the tip\r
+ of the current <link linkend="def_branch">branch</link> as a new commit.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_clean" xreflabel="[def_clean]"/>clean\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A <link linkend="def_working_tree">working tree</link> is clean, if it\r
+ corresponds to the <link linkend="def_revision">revision</link> referenced by the current\r
+ <link linkend="def_head">head</link>. Also see "<link linkend="def_dirty">dirty</link>".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_commit" xreflabel="[def_commit]"/>commit\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ As a noun: A single point in the\r
+ git history; the entire history of a project is represented as a\r
+ set of interrelated commits. The word "commit" is often\r
+ used by git in the same places other revision control systems\r
+ use the words "revision" or "version". Also used as a short\r
+ hand for <link linkend="def_commit_object">commit object</link>.\r
+</simpara>\r
+<simpara>As a verb: The action of storing a new snapshot of the project’s\r
+state in the git history, by creating a new commit representing the current\r
+state of the <link linkend="def_index">index</link> and advancing <link linkend="def_HEAD">HEAD</link>\r
+to point at the new commit.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_commit_object" xreflabel="[def_commit_object]"/>commit object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An <link linkend="def_object">object</link> which contains the information about a\r
+ particular <link linkend="def_revision">revision</link>, such as <link linkend="def_parent">parents</link>, committer,\r
+ author, date and the <link linkend="def_tree_object">tree object</link> which corresponds\r
+ to the top <link linkend="def_directory">directory</link> of the stored\r
+ revision.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_core_git" xreflabel="[def_core_git]"/>core git\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Fundamental data structures and utilities of git. Exposes only limited\r
+ source code management tools.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_DAG" xreflabel="[def_DAG]"/>DAG\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Directed acyclic graph. The <link linkend="def_commit_object">commit objects</link> form a\r
+ directed acyclic graph, because they have parents (directed), and the\r
+ graph of commit objects is acyclic (there is no <link linkend="def_chain">chain</link>\r
+ which begins and ends with the same <link linkend="def_object">object</link>).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_dangling_object" xreflabel="[def_dangling_object]"/>dangling object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An <link linkend="def_unreachable_object">unreachable object</link> which is not\r
+ <link linkend="def_reachable">reachable</link> even from other unreachable objects; a\r
+ dangling object has no references to it from any\r
+ reference or <link linkend="def_object">object</link> in the <link linkend="def_repository">repository</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_detached_HEAD" xreflabel="[def_detached_HEAD]"/>detached HEAD\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Normally the <link linkend="def_HEAD">HEAD</link> stores the name of a\r
+ <link linkend="def_branch">branch</link>. However, git also allows you to <link linkend="def_checkout">check out</link>\r
+ an arbitrary <link linkend="def_commit">commit</link> that isn’t necessarily the tip of any\r
+ particular branch. In this case HEAD is said to be "detached".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_dircache" xreflabel="[def_dircache]"/>dircache\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ You are <emphasis role="strong">waaaaay</emphasis> behind. See <link linkend="def_index">index</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_directory" xreflabel="[def_directory]"/>directory\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The list you get with "ls" :-)\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_dirty" xreflabel="[def_dirty]"/>dirty\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A <link linkend="def_working_tree">working tree</link> is said to be "dirty" if\r
+ it contains modifications which have not been <link linkend="def_commit">committed</link> to the current\r
+ <link linkend="def_branch">branch</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_ent" xreflabel="[def_ent]"/>ent\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Favorite synonym to "<link linkend="def_tree-ish">tree-ish</link>" by some total geeks. See\r
+ <literal>http://en.wikipedia.org/wiki/Ent_(Middle-earth)</literal> for an in-depth\r
+ explanation. Avoid this term, not to confuse people.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_evil_merge" xreflabel="[def_evil_merge]"/>evil merge\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An evil merge is a <link linkend="def_merge">merge</link> that introduces changes that\r
+ do not appear in any <link linkend="def_parent">parent</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_fast_forward" xreflabel="[def_fast_forward]"/>fast forward\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A fast-forward is a special type of <link linkend="def_merge">merge</link> where you have a\r
+ <link linkend="def_revision">revision</link> and you are "merging" another\r
+ <link linkend="def_branch">branch</link>'s changes that happen to be a descendant of what\r
+ you have. In such these cases, you do not make a new <link linkend="def_merge">merge</link>\r
+ <link linkend="def_commit">commit</link> but instead just update to his\r
+ revision. This will happen frequently on a\r
+ <link linkend="def_tracking_branch">tracking branch</link> of a remote\r
+ <link linkend="def_repository">repository</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_fetch" xreflabel="[def_fetch]"/>fetch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Fetching a <link linkend="def_branch">branch</link> means to get the\r
+ branch’s <link linkend="def_head_ref">head ref</link> from a remote\r
+ <link linkend="def_repository">repository</link>, to find out which objects are\r
+ missing from the local <link linkend="def_object_database">object database</link>,\r
+ and to get them, too. See also <xref linkend="git-fetch(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_file_system" xreflabel="[def_file_system]"/>file system\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Linus Torvalds originally designed git to be a user space file system,\r
+ i.e. the infrastructure to hold files and directories. That ensured the\r
+ efficiency and speed of git.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_git_archive" xreflabel="[def_git_archive]"/>git archive\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Synonym for <link linkend="def_repository">repository</link> (for arch people).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_grafts" xreflabel="[def_grafts]"/>grafts\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Grafts enables two otherwise different lines of development to be joined\r
+ together by recording fake ancestry information for commits. This way\r
+ you can make git pretend the set of <link linkend="def_parent">parents</link> a <link linkend="def_commit">commit</link> has\r
+ is different from what was recorded when the commit was\r
+ created. Configured via the <literal>.git/info/grafts</literal> file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_hash" xreflabel="[def_hash]"/>hash\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ In git’s context, synonym to <link linkend="def_object_name">object name</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_head" xreflabel="[def_head]"/>head\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A <link linkend="def_ref">named reference</link> to the <link linkend="def_commit">commit</link> at the tip of a\r
+ <link linkend="def_branch">branch</link>. Heads are stored in\r
+ <literal>$GIT_DIR/refs/heads/</literal>, except when using packed refs. (See\r
+ <xref linkend="git-pack-refs(1)"/>.)\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_HEAD" xreflabel="[def_HEAD]"/>HEAD\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The current <link linkend="def_branch">branch</link>. In more detail: Your <link linkend="def_working_tree">working tree</link> is normally derived from the state of the tree\r
+ referred to by HEAD. HEAD is a reference to one of the\r
+ <link linkend="def_head">heads</link> in your repository, except when using a\r
+ <link linkend="def_detached_HEAD">detached HEAD</link>, in which case it may\r
+ reference an arbitrary commit.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_head_ref" xreflabel="[def_head_ref]"/>head ref\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A synonym for <link linkend="def_head">head</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_hook" xreflabel="[def_hook]"/>hook\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ During the normal execution of several git commands, call-outs are made\r
+ to optional scripts that allow a developer to add functionality or\r
+ checking. Typically, the hooks allow for a command to be pre-verified\r
+ and potentially aborted, and allow for a post-notification after the\r
+ operation is done. The hook scripts are found in the\r
+ <literal>$GIT_DIR/hooks/</literal> directory, and are enabled by simply\r
+ removing the <literal>.sample</literal> suffix from the filename. In earlier versions\r
+ of git you had to make them executable.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_index" xreflabel="[def_index]"/>index\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A collection of files with stat information, whose contents are stored\r
+ as objects. The index is a stored version of your\r
+ <link linkend="def_working_tree">working tree</link>. Truth be told, it can also contain a second, and even\r
+ a third version of a working tree, which are used\r
+ when <link linkend="def_merge">merging</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_index_entry" xreflabel="[def_index_entry]"/>index entry\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The information regarding a particular file, stored in the\r
+ <link linkend="def_index">index</link>. An index entry can be unmerged, if a\r
+ <link linkend="def_merge">merge</link> was started, but not yet finished (i.e. if\r
+ the index contains multiple versions of that file).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_master" xreflabel="[def_master]"/>master\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The default development <link linkend="def_branch">branch</link>. Whenever you\r
+ create a git <link linkend="def_repository">repository</link>, a branch named\r
+ "master" is created, and becomes the active branch. In most\r
+ cases, this contains the local development, though that is\r
+ purely by convention and is not required.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_merge" xreflabel="[def_merge]"/>merge\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ As a verb: To bring the contents of another\r
+ <link linkend="def_branch">branch</link> (possibly from an external\r
+ <link linkend="def_repository">repository</link>) into the current branch. In the\r
+ case where the merged-in branch is from a different repository,\r
+ this is done by first <link linkend="def_fetch">fetching</link> the remote branch\r
+ and then merging the result into the current branch. This\r
+ combination of fetch and merge operations is called a\r
+ <link linkend="def_pull">pull</link>. Merging is performed by an automatic process\r
+ that identifies changes made since the branches diverged, and\r
+ then applies all those changes together. In cases where changes\r
+ conflict, manual intervention may be required to complete the\r
+ merge.\r
+</simpara>\r
+<simpara>As a noun: unless it is a <link linkend="def_fast_forward">fast forward</link>, a\r
+successful merge results in the creation of a new <link linkend="def_commit">commit</link>\r
+representing the result of the merge, and having as\r
+<link linkend="def_parent">parents</link> the tips of the merged <link linkend="def_branch">branches</link>.\r
+This commit is referred to as a "merge commit", or sometimes just a\r
+"merge".</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_object" xreflabel="[def_object]"/>object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The unit of storage in git. It is uniquely identified by the\r
+ <link linkend="def_SHA1">SHA1</link> of its contents. Consequently, an\r
+ object can not be changed.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_object_database" xreflabel="[def_object_database]"/>object database\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Stores a set of "objects", and an individual <link linkend="def_object">object</link> is\r
+ identified by its <link linkend="def_object_name">object name</link>. The objects usually\r
+ live in <literal>$GIT_DIR/objects/</literal>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_object_identifier" xreflabel="[def_object_identifier]"/>object identifier\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Synonym for <link linkend="def_object_name">object name</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_object_name" xreflabel="[def_object_name]"/>object name\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The unique identifier of an <link linkend="def_object">object</link>. The <link linkend="def_hash">hash</link>\r
+ of the object’s contents using the Secure Hash Algorithm\r
+ 1 and usually represented by the 40 character hexadecimal encoding of\r
+ the <link linkend="def_hash">hash</link> of the object.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_object_type" xreflabel="[def_object_type]"/>object type\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ One of the identifiers "<link linkend="def_commit_object">commit</link>",\r
+ "<link linkend="def_tree_object">tree</link>", "<link linkend="def_tag_object">tag</link>" or\r
+ "<link linkend="def_blob_object">blob</link>" describing the type of an\r
+ <link linkend="def_object">object</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_octopus" xreflabel="[def_octopus]"/>octopus\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ To <link linkend="def_merge">merge</link> more than two <link linkend="def_branch">branches</link>. Also denotes an\r
+ intelligent predator.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_origin" xreflabel="[def_origin]"/>origin\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The default upstream <link linkend="def_repository">repository</link>. Most projects have\r
+ at least one upstream project which they track. By default\r
+ <emphasis>origin</emphasis> is used for that purpose. New upstream updates\r
+ will be fetched into remote <link linkend="def_tracking_branch">tracking branches</link> named\r
+ origin/name-of-upstream-branch, which you can see using\r
+ "<literal>git branch -r</literal>".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_pack" xreflabel="[def_pack]"/>pack\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A set of objects which have been compressed into one file (to save space\r
+ or to transmit them efficiently).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_pack_index" xreflabel="[def_pack_index]"/>pack index\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The list of identifiers, and other information, of the objects in a\r
+ <link linkend="def_pack">pack</link>, to assist in efficiently accessing the contents of a\r
+ pack.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_parent" xreflabel="[def_parent]"/>parent\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A <link linkend="def_commit_object">commit object</link> contains a (possibly empty) list\r
+ of the logical predecessor(s) in the line of development, i.e. its\r
+ parents.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_pickaxe" xreflabel="[def_pickaxe]"/>pickaxe\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The term <link linkend="def_pickaxe">pickaxe</link> refers to an option to the diffcore\r
+ routines that help select changes that add or delete a given text\r
+ string. With the <literal>--pickaxe-all</literal> option, it can be used to view the full\r
+ <link linkend="def_changeset">changeset</link> that introduced or removed, say, a\r
+ particular line of text. See <xref linkend="git-diff(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_plumbing" xreflabel="[def_plumbing]"/>plumbing\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Cute name for <link linkend="def_core_git">core git</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_porcelain" xreflabel="[def_porcelain]"/>porcelain\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Cute name for programs and program suites depending on\r
+ <link linkend="def_core_git">core git</link>, presenting a high level access to\r
+ core git. Porcelains expose more of a <link linkend="def_SCM">SCM</link>\r
+ interface than the <link linkend="def_plumbing">plumbing</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_pull" xreflabel="[def_pull]"/>pull\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Pulling a <link linkend="def_branch">branch</link> means to <link linkend="def_fetch">fetch</link> it and\r
+ <link linkend="def_merge">merge</link> it. See also <xref linkend="git-pull(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_push" xreflabel="[def_push]"/>push\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Pushing a <link linkend="def_branch">branch</link> means to get the branch’s\r
+ <link linkend="def_head_ref">head ref</link> from a remote <link linkend="def_repository">repository</link>,\r
+ find out if it is a direct ancestor to the branch’s local\r
+ head ref, and in that case, putting all\r
+ objects, which are <link linkend="def_reachable">reachable</link> from the local\r
+ head ref, and which are missing from the remote\r
+ repository, into the remote\r
+ <link linkend="def_object_database">object database</link>, and updating the remote\r
+ head ref. If the remote <link linkend="def_head">head</link> is not an\r
+ ancestor to the local head, the push fails.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_reachable" xreflabel="[def_reachable]"/>reachable\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ All of the ancestors of a given <link linkend="def_commit">commit</link> are said to be\r
+ "reachable" from that commit. More\r
+ generally, one <link linkend="def_object">object</link> is reachable from\r
+ another if we can reach the one from the other by a <link linkend="def_chain">chain</link>\r
+ that follows <link linkend="def_tag">tags</link> to whatever they tag,\r
+ <link linkend="def_commit_object">commits</link> to their parents or trees, and\r
+ <link linkend="def_tree_object">trees</link> to the trees or <link linkend="def_blob_object">blobs</link>\r
+ that they contain.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_rebase" xreflabel="[def_rebase]"/>rebase\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ To reapply a series of changes from a <link linkend="def_branch">branch</link> to a\r
+ different base, and reset the <link linkend="def_head">head</link> of that branch\r
+ to the result.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_ref" xreflabel="[def_ref]"/>ref\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A 40-byte hex representation of a <link linkend="def_SHA1">SHA1</link> or a name that\r
+ denotes a particular <link linkend="def_object">object</link>. These may be stored in\r
+ <literal>$GIT_DIR/refs/</literal>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_reflog" xreflabel="[def_reflog]"/>reflog\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A reflog shows the local "history" of a ref. In other words,\r
+ it can tell you what the 3rd last revision in <emphasis>this</emphasis> repository\r
+ was, and what was the current state in <emphasis>this</emphasis> repository,\r
+ yesterday 9:14pm. See <xref linkend="git-reflog(1)"/> for details.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_refspec" xreflabel="[def_refspec]"/>refspec\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A "refspec" is used by <link linkend="def_fetch">fetch</link> and\r
+ <link linkend="def_push">push</link> to describe the mapping between remote\r
+ <link linkend="def_ref">ref</link> and local ref. They are combined with a colon in\r
+ the format <src>:<dst>, preceded by an optional plus sign, +.\r
+ For example: <literal>git fetch $URL\r
+ refs/heads/master:refs/heads/origin</literal> means "grab the master\r
+ <link linkend="def_branch">branch</link> <link linkend="def_head">head</link> from the $URL and store\r
+ it as my origin branch head". And <literal>git push\r
+ $URL refs/heads/master:refs/heads/to-upstream</literal> means "publish my\r
+ master branch head as to-upstream branch at $URL". See also\r
+ <xref linkend="git-push(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_repository" xreflabel="[def_repository]"/>repository\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A collection of <link linkend="def_ref">refs</link> together with an\r
+ <link linkend="def_object_database">object database</link> containing all objects\r
+ which are <link linkend="def_reachable">reachable</link> from the refs, possibly\r
+ accompanied by meta data from one or more <link linkend="def_porcelain">porcelains</link>. A\r
+ repository can share an object database with other repositories\r
+ via <link linkend="def_alternate_object_database">alternates mechanism</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_resolve" xreflabel="[def_resolve]"/>resolve\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The action of fixing up manually what a failed automatic\r
+ <link linkend="def_merge">merge</link> left behind.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_revision" xreflabel="[def_revision]"/>revision\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A particular state of files and directories which was stored in the\r
+ <link linkend="def_object_database">object database</link>. It is referenced by a\r
+ <link linkend="def_commit_object">commit object</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_rewind" xreflabel="[def_rewind]"/>rewind\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ To throw away part of the development, i.e. to assign the\r
+ <link linkend="def_head">head</link> to an earlier <link linkend="def_revision">revision</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_SCM" xreflabel="[def_SCM]"/>SCM\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Source code management (tool).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_SHA1" xreflabel="[def_SHA1]"/>SHA1\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Synonym for <link linkend="def_object_name">object name</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_shallow_repository" xreflabel="[def_shallow_repository]"/>shallow repository\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A shallow <link linkend="def_repository">repository</link> has an incomplete\r
+ history some of whose <link linkend="def_commit">commits</link> have <link linkend="def_parent">parents</link> cauterized away (in other\r
+ words, git is told to pretend that these commits do not have the\r
+ parents, even though they are recorded in the <link linkend="def_commit_object">commit object</link>). This is sometimes useful when you are interested only in the\r
+ recent history of a project even though the real history recorded in the\r
+ upstream is much larger. A shallow repository\r
+ is created by giving the <literal>--depth</literal> option to <xref linkend="git-clone(1)"/>, and\r
+ its history can be later deepened with <xref linkend="git-fetch(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_symref" xreflabel="[def_symref]"/>symref\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Symbolic reference: instead of containing the <link linkend="def_SHA1">SHA1</link>\r
+ id itself, it is of the format <emphasis>ref: refs/some/thing</emphasis> and when\r
+ referenced, it recursively dereferences to this reference.\r
+ <emphasis><link linkend="def_HEAD">HEAD</link></emphasis> is a prime example of a symref. Symbolic\r
+ references are manipulated with the <xref linkend="git-symbolic-ref(1)"/>\r
+ command.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_tag" xreflabel="[def_tag]"/>tag\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A <link linkend="def_ref">ref</link> pointing to a <link linkend="def_tag_object">tag</link> or\r
+ <link linkend="def_commit_object">commit object</link>. In contrast to a <link linkend="def_head">head</link>,\r
+ a tag is not changed by a <link linkend="def_commit">commit</link>. Tags (not\r
+ <link linkend="def_tag_object">tag objects</link>) are stored in <literal>$GIT_DIR/refs/tags/</literal>. A\r
+ git tag has nothing to do with a Lisp tag (which would be\r
+ called an <link linkend="def_object_type">object type</link> in git’s context). A\r
+ tag is most typically used to mark a particular point in the\r
+ commit ancestry <link linkend="def_chain">chain</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_tag_object" xreflabel="[def_tag_object]"/>tag object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An <link linkend="def_object">object</link> containing a <link linkend="def_ref">ref</link> pointing to\r
+ another object, which can contain a message just like a\r
+ <link linkend="def_commit_object">commit object</link>. It can also contain a (PGP)\r
+ signature, in which case it is called a "signed tag object".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_topic_branch" xreflabel="[def_topic_branch]"/>topic branch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A regular git <link linkend="def_branch">branch</link> that is used by a developer to\r
+ identify a conceptual line of development. Since branches are very easy\r
+ and inexpensive, it is often desirable to have several small branches\r
+ that each contain very well defined concepts or small incremental yet\r
+ related changes.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_tracking_branch" xreflabel="[def_tracking_branch]"/>tracking branch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A regular git <link linkend="def_branch">branch</link> that is used to follow changes from\r
+ another <link linkend="def_repository">repository</link>. A tracking\r
+ branch should not contain direct modifications or have local commits\r
+ made to it. A tracking branch can usually be\r
+ identified as the right-hand-side <link linkend="def_ref">ref</link> in a Pull:\r
+ <link linkend="def_refspec">refspec</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_tree" xreflabel="[def_tree]"/>tree\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ Either a <link linkend="def_working_tree">working tree</link>, or a <link linkend="def_tree_object">tree object</link> together with the dependent <link linkend="def_blob_object">blob</link> and tree objects\r
+ (i.e. a stored representation of a working tree).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_tree_object" xreflabel="[def_tree_object]"/>tree object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An <link linkend="def_object">object</link> containing a list of file names and modes along\r
+ with refs to the associated blob and/or tree objects. A\r
+ <link linkend="def_tree">tree</link> is equivalent to a <link linkend="def_directory">directory</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_tree-ish" xreflabel="[def_tree-ish]"/>tree-ish\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ A <link linkend="def_ref">ref</link> pointing to either a <link linkend="def_commit_object">commit object</link>, a <link linkend="def_tree_object">tree object</link>, or a <link linkend="def_tag_object">tag object</link> pointing to a tag or commit or tree object.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_unmerged_index" xreflabel="[def_unmerged_index]"/>unmerged index\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An <link linkend="def_index">index</link> which contains unmerged\r
+ <link linkend="def_index_entry">index entries</link>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_unreachable_object" xreflabel="[def_unreachable_object]"/>unreachable object\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ An <link linkend="def_object">object</link> which is not <link linkend="def_reachable">reachable</link> from a\r
+ <link linkend="def_branch">branch</link>, <link linkend="def_tag">tag</link>, or any other reference.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<anchor id="def_working_tree" xreflabel="[def_working_tree]"/>working tree\r
+</term>\r
+<listitem>\r
+<simpara>\r
+ The tree of actual checked out files. The working tree is\r
+ normally equal to the <link linkend="def_HEAD">HEAD</link> plus any local changes\r
+ that you have made but not yet committed.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="gittutorial(7)"/>,\r
+<xref linkend="gittutorial-2(7)"/>,\r
+<xref linkend="gitcvs-migration(7)"/>,\r
+<ulink url="everyday.html">Everyday git</ulink>,\r
+<ulink url="user-manual.html">The Git User’s Manual</ulink></simpara>\r
+</simplesect>\r
+<simplesect id="_git">\r
+<title>GIT</title>\r
+<simpara>Part of the <xref linkend="git(1)"/> suite.</simpara>\r
+</simplesect>\r
+</article>\r
OSDN Git Service
