summaryrefslogtreecommitdiff
path: root/Documentation/revisions.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/revisions.txt')
-rw-r--r--Documentation/revisions.txt97
1 files changed, 78 insertions, 19 deletions
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index b290b617d4..07961185fe 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -2,13 +2,13 @@ SPECIFYING REVISIONS
--------------------
A revision parameter '<rev>' typically, but not necessarily, names a
-commit object. It uses what is called an 'extended SHA1'
+commit object. It uses what is called an 'extended SHA-1'
syntax. Here are various ways to spell object names. The
ones listed near the end of this list name trees and
blobs contained in a commit.
'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
- The full SHA1 object name (40-byte hexadecimal string), or
+ The full SHA-1 object name (40-byte hexadecimal string), or
a leading substring that is unique within the repository.
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
name the same commit object if there is no other object in
@@ -23,23 +23,23 @@ blobs contained in a commit.
A symbolic ref name. E.g. 'master' typically means the commit
object referenced by 'refs/heads/master'. If you
happen to have both 'heads/master' and 'tags/master', you can
- explicitly say 'heads/master' to tell git which one you mean.
- When ambiguous, a '<name>' is disambiguated by taking the
+ explicitly say 'heads/master' to tell Git which one you mean.
+ When ambiguous, a '<refname>' is disambiguated by taking the
first match in the following rules:
- . If '$GIT_DIR/<name>' exists, that is what you mean (this is usually
+ . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
useful only for 'HEAD', 'FETCH_HEAD', 'ORIG_HEAD', 'MERGE_HEAD'
and 'CHERRY_PICK_HEAD');
- . otherwise, 'refs/<name>' if it exists;
+ . otherwise, 'refs/<refname>' if it exists;
. otherwise, 'refs/tags/<refname>' if it exists;
- . otherwise, 'refs/heads/<name>' if it exists;
+ . otherwise, 'refs/heads/<refname>' if it exists;
- . otherwise, 'refs/remotes/<name>' if it exists;
+ . otherwise, 'refs/remotes/<refname>' if it exists;
- . otherwise, 'refs/remotes/<name>/HEAD' if it exists.
+ . otherwise, 'refs/remotes/<refname>/HEAD' if it exists.
+
'HEAD' names the commit on which you based the changes in the working tree.
'FETCH_HEAD' records the branch which you fetched from a remote repository
@@ -55,6 +55,11 @@ when you run `git cherry-pick`.
+
Note that any of the 'refs/*' cases above may come either from
the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
+While the ref name encoding is unspecified, UTF-8 is preferred as
+some output processing may assume ref names in UTF-8.
+
+'@'::
+ '@' alone is a shortcut for 'HEAD'.
'<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}'::
A ref followed by the suffix '@' with a date specification
@@ -83,13 +88,15 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.
'@\{-<n>\}', e.g. '@\{-1\}'::
- The construct '@\{-<n>\}' means the <n>th branch checked out
+ The construct '@\{-<n>\}' means the <n>th branch/commit checked out
before the current one.
-'<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
- The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to
- the branch the ref is set to build on top of. A missing ref defaults
- to the current branch.
+'<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
+ The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')
+ refers to the branch that the branch specified by branchname is set to build on
+ top of (configured with `branch.<name>.remote` and
+ `branch.<name>.merge`). A missing branchname defaults to the
+ current one.
'<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
A suffix '{caret}' to a revision parameter means the first parent of
@@ -101,7 +108,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
'<rev>{tilde}<n>', e.g. 'master{tilde}3'::
A suffix '{tilde}<n>' to a revision parameter means the commit
- object that is the <n>th generation grand-parent of the named
+ object that is the <n>th generation ancestor of the named
commit object, following only the first parents. I.e. '<rev>{tilde}3' is
equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to
'<rev>{caret}1{caret}1{caret}1'. See below for an illustration of
@@ -109,11 +116,23 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
'<rev>{caret}\{<type>\}', e.g. 'v0.99.8{caret}\{commit\}'::
A suffix '{caret}' followed by an object type name enclosed in
- brace pair means the object
- could be a tag, and dereference the tag recursively until an
- object of that type is found or the object cannot be
- dereferenced anymore (in which case, barf). '<rev>{caret}0'
+ brace pair means dereference the object at '<rev>' recursively until
+ an object of type '<type>' is found or the object cannot be
+ dereferenced anymore (in which case, barf).
+ For example, if '<rev>' is a commit-ish, '<rev>{caret}\{commit\}'
+ describes the corresponding commit object.
+ Similarly, if '<rev>' is a tree-ish, '<rev>{caret}\{tree\}'
+ describes the corresponding tree object.
+ '<rev>{caret}0'
is a short-hand for '<rev>{caret}\{commit\}'.
++
+'rev{caret}\{object\}' can be used to make sure 'rev' names an
+object that exists, without requiring 'rev' to be a tag, and
+without dereferencing 'rev'; because a tag is already an object,
+it does not have to be dereferenced even once to get to an object.
++
+'rev{caret}\{tag\}' can be used to ensure that 'rev' identifies an
+existing tag object.
'<rev>{caret}\{\}', e.g. 'v0.99.8{caret}\{\}'::
A suffix '{caret}' followed by an empty brace pair
@@ -213,18 +232,58 @@ of 'r1' and 'r2' and is defined as
It is the set of commits that are reachable from either one of
'r1' or 'r2' but not from both.
+In these two shorthands, you can omit one end and let it default to HEAD.
+For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What
+did I do since I forked from the origin branch?" Similarly, '..origin'
+is a shorthand for 'HEAD..origin' and asks "What did the origin do since
+I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an
+empty range that is both reachable and unreachable from HEAD.
+
Two other shorthands for naming a set that is formed by a commit
and its parent commits exist. The 'r1{caret}@' notation means all
parents of 'r1'. 'r1{caret}!' includes commit 'r1' but excludes
all of its parents.
+To summarize:
+
+'<rev>'::
+ Include commits that are reachable from (i.e. ancestors of)
+ <rev>.
+
+'{caret}<rev>'::
+ Exclude commits that are reachable from (i.e. ancestors of)
+ <rev>.
+
+'<rev1>..<rev2>'::
+ Include commits that are reachable from <rev2> but exclude
+ those that are reachable from <rev1>. When either <rev1> or
+ <rev2> is omitted, it defaults to 'HEAD'.
+
+'<rev1>\...<rev2>'::
+ Include commits that are reachable from either <rev1> or
+ <rev2> but exclude those that are reachable from both. When
+ either <rev1> or <rev2> is omitted, it defaults to 'HEAD'.
+
+'<rev>{caret}@', e.g. 'HEAD{caret}@'::
+ A suffix '{caret}' followed by an at sign is the same as listing
+ all parents of '<rev>' (meaning, include anything reachable from
+ its parents, but not the commit itself).
+
+'<rev>{caret}!', e.g. 'HEAD{caret}!'::
+ A suffix '{caret}' followed by an exclamation mark is the same
+ as giving commit '<rev>' and then all its parents prefixed with
+ '{caret}' to exclude them (and their ancestors).
+
Here are a handful of examples:
D G H D
D F G H I J D F
^G D H D
^D B E I J F B
+ B..C C
B...C G H D E B C
^D B C E I J F B C
+ C I J F C
C^@ I J F
+ C^! C
F^! D G H D F