Fix typo in 1.7.9 release notes
[gitweb.git] / Documentation / glossary-content.txt
index 1f029f8aa080c4de6323e8b4905a81fa7e8e2046..3595b586bc35d865a08ab538a1908cb2abe8e1a8 100644 (file)
@@ -131,7 +131,7 @@ to point at the new commit.
        you have. In such these cases, you do not make a new <<def_merge,merge>>
        <<def_commit,commit>> but instead just update to his
        revision. This will happen frequently on a
-       <<def_tracking_branch,tracking branch>> of a remote
+       <<def_remote_tracking_branch,remote-tracking branch>> of a remote
        <<def_repository,repository>>.
 
 [[def_fetch]]fetch::
@@ -161,8 +161,8 @@ to point at the new commit.
 
 [[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
-       `$GIT_DIR/refs/heads/`, except when using packed refs. (See
+       <<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::
@@ -170,8 +170,8 @@ to point at the new commit.
        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 may
-       reference an arbitrary commit.
+       <<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>>.
@@ -260,7 +260,7 @@ This commit is referred to as a "merge commit", or sometimes just a
        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 remote <<def_tracking_branch,tracking branches>> named
+       will be fetched into remote <<def_remote_tracking_branch,remote-tracking branches>> named
        origin/name-of-upstream-branch, which you can see using
        `git branch -r`.
 
@@ -273,6 +273,61 @@ This commit is referred to as a "merge commit", or sometimes just a
        <<def_pack,pack>>, to assist in efficiently accessing the contents of a
        pack.
 
+[[def_pathspec]]pathspec::
+       Pattern used to specify paths.
++
+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
+worktree.  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 optional
+colon that terminates the "magic signature" can be omitted if the pattern
+begins with a character that cannot be a "magic signature" and is not a
+colon.
++
+In the long form, the leading colon `:` is followed by a 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.
++
+The "magic signature" consists of an ASCII symbol that is not
+alphanumeric.
++
+--
+top `/`;;
+       The magic word `top` (mnemonic: `/`) makes the pattern match
+       from the root of the working tree, even when you are running
+       the command from inside a subdirectory.
+--
++
+Currently only the slash `/` is recognized as the "magic signature",
+but it is envisioned that we will support more types of magic in later
+versions of git.
++
+A pathspec with only a colon means "there is no pathspec". This form
+should not be combined with other 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
@@ -327,8 +382,9 @@ This commit is referred to as a "merge commit", or sometimes just a
 
 [[def_ref]]ref::
        A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
-       denotes a particular <<def_object,object>>. These may be stored in
-       `$GIT_DIR/refs/`.
+       denotes a particular <<def_object,object>>. They may be stored in
+       a file under `$GIT_DIR/refs/` directory, or
+       in the `$GIT_DIR/packed-refs` file.
 
 [[def_reflog]]reflog::
        A reflog shows the local "history" of a ref.  In other words,
@@ -349,6 +405,14 @@ This commit is referred to as a "merge commit", or sometimes just a
        master branch head as to-upstream branch at $URL". See also
        linkgit:git-push[1].
 
+[[def_remote_tracking_branch]]remote-tracking branch::
+       A regular git <<def_branch,branch>> that is used to follow changes from
+       another <<def_repository,repository>>. A remote-tracking
+       branch should not contain direct modifications or have local commits
+       made to it. A remote-tracking branch can usually be
+       identified as the right-hand-side <<def_ref,ref>> in a Pull:
+       <<def_refspec,refspec>>.
+
 [[def_repository]]repository::
        A collection of <<def_ref,refs>> together with an
        <<def_object_database,object database>> containing all objects
@@ -396,14 +460,14 @@ This commit is referred to as a "merge commit", or sometimes just a
        command.
 
 [[def_tag]]tag::
-       A <<def_ref,ref>> pointing to a <<def_tag_object,tag>> or
-       <<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
-       a tag is not changed by a <<def_commit,commit>>. Tags (not
-       <<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. 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>>.
+       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
@@ -418,14 +482,6 @@ This commit is referred to as a "merge commit", or sometimes just a
        that each contain very well defined concepts or small incremental yet
        related changes.
 
-[[def_tracking_branch]]tracking branch::
-       A regular git <<def_branch,branch>> that is used to follow changes from
-       another <<def_repository,repository>>. A tracking
-       branch should not contain direct modifications or have local commits
-       made to it. A tracking branch can usually be
-       identified as the right-hand-side <<def_ref,ref>> in a Pull:
-       <<def_refspec,refspec>>.
-
 [[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