| '\" t |
| .\" Title: gitrevisions |
| .\" Author: [FIXME: author] [see http://docbook.sf.net/el/author] |
| .\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/> |
| .\" Date: 06/08/2020 |
| .\" Manual: Git Manual |
| .\" Source: Git 2.27.0.83.g0313f36c6e |
| .\" Language: English |
| .\" |
| .TH "GITREVISIONS" "7" "06/08/2020" "Git 2\&.27\&.0\&.83\&.g0313f36" "Git Manual" |
| .\" ----------------------------------------------------------------- |
| .\" * Define some portability stuff |
| .\" ----------------------------------------------------------------- |
| .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| .\" http://bugs.debian.org/507673 |
| .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html |
| .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| .ie \n(.g .ds Aq \(aq |
| .el .ds Aq ' |
| .\" ----------------------------------------------------------------- |
| .\" * set default formatting |
| .\" ----------------------------------------------------------------- |
| .\" disable hyphenation |
| .nh |
| .\" disable justification (adjust text to left margin only) |
| .ad l |
| .\" ----------------------------------------------------------------- |
| .\" * MAIN CONTENT STARTS HERE * |
| .\" ----------------------------------------------------------------- |
| .SH "NAME" |
| gitrevisions \- Specifying revisions and ranges for Git |
| .SH "SYNOPSIS" |
| .sp |
| gitrevisions |
| .SH "DESCRIPTION" |
| .sp |
| Many Git commands take revision parameters as arguments\&. Depending on the command, they denote a specific commit or, for commands which walk the revision graph (such as \fBgit-log\fR(1)), all commits which are reachable from that commit\&. For commands that walk the revision graph one can also specify a range of revisions explicitly\&. |
| .sp |
| In addition, some Git commands (such as \fBgit-show\fR(1) and \fBgit-push\fR(1)) can also take revision parameters which denote other objects than commits, e\&.g\&. blobs ("files") or trees ("directories of files")\&. |
| .SH "SPECIFYING REVISIONS" |
| .sp |
| A revision parameter \fI<rev>\fR typically, but not necessarily, names a commit object\&. It uses what is called an \fIextended SHA\-1\fR 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\&. |
| .if n \{\ |
| .sp |
| .\} |
| .RS 4 |
| .it 1 an-trap |
| .nr an-no-space-flag 1 |
| .nr an-break-flag 1 |
| .br |
| .ps +1 |
| \fBNote\fR |
| .ps -1 |
| .br |
| .sp |
| This document shows the "raw" syntax as seen by git\&. The shell and other UIs might require additional quoting to protect special characters and to avoid word splitting\&. |
| .sp .5v |
| .RE |
| .PP |
| \fI<sha1>\fR, e\&.g\&. \fIdae86e1950b1277e545cee180551750029cfe735\fR, \fIdae86e\fR |
| .RS 4 |
| 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 your repository whose object name starts with dae86e\&. |
| .RE |
| .PP |
| \fI<describeOutput>\fR, e\&.g\&. \fIv1\&.7\&.4\&.2\-679\-g3bee7fb\fR |
| .RS 4 |
| Output from |
| \fBgit describe\fR; i\&.e\&. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a |
| \fIg\fR, and an abbreviated object name\&. |
| .RE |
| .PP |
| \fI<refname>\fR, e\&.g\&. \fImaster\fR, \fIheads/master\fR, \fIrefs/heads/master\fR |
| .RS 4 |
| A symbolic ref name\&. E\&.g\&. |
| \fImaster\fR |
| typically means the commit object referenced by |
| \fIrefs/heads/master\fR\&. If you happen to have both |
| \fIheads/master\fR |
| and |
| \fItags/master\fR, you can explicitly say |
| \fIheads/master\fR |
| to tell Git which one you mean\&. When ambiguous, a |
| \fI<refname>\fR |
| is disambiguated by taking the first match in the following rules: |
| .sp |
| .RS 4 |
| .ie n \{\ |
| \h'-04' 1.\h'+01'\c |
| .\} |
| .el \{\ |
| .sp -1 |
| .IP " 1." 4.2 |
| .\} |
| If |
| \fI$GIT_DIR/<refname>\fR |
| exists, that is what you mean (this is usually useful only for |
| \fBHEAD\fR, |
| \fBFETCH_HEAD\fR, |
| \fBORIG_HEAD\fR, |
| \fBMERGE_HEAD\fR |
| and |
| \fBCHERRY_PICK_HEAD\fR); |
| .RE |
| .sp |
| .RS 4 |
| .ie n \{\ |
| \h'-04' 2.\h'+01'\c |
| .\} |
| .el \{\ |
| .sp -1 |
| .IP " 2." 4.2 |
| .\} |
| otherwise, |
| \fIrefs/<refname>\fR |
| if it exists; |
| .RE |
| .sp |
| .RS 4 |
| .ie n \{\ |
| \h'-04' 3.\h'+01'\c |
| .\} |
| .el \{\ |
| .sp -1 |
| .IP " 3." 4.2 |
| .\} |
| otherwise, |
| \fIrefs/tags/<refname>\fR |
| if it exists; |
| .RE |
| .sp |
| .RS 4 |
| .ie n \{\ |
| \h'-04' 4.\h'+01'\c |
| .\} |
| .el \{\ |
| .sp -1 |
| .IP " 4." 4.2 |
| .\} |
| otherwise, |
| \fIrefs/heads/<refname>\fR |
| if it exists; |
| .RE |
| .sp |
| .RS 4 |
| .ie n \{\ |
| \h'-04' 5.\h'+01'\c |
| .\} |
| .el \{\ |
| .sp -1 |
| .IP " 5." 4.2 |
| .\} |
| otherwise, |
| \fIrefs/remotes/<refname>\fR |
| if it exists; |
| .RE |
| .sp |
| .RS 4 |
| .ie n \{\ |
| \h'-04' 6.\h'+01'\c |
| .\} |
| .el \{\ |
| .sp -1 |
| .IP " 6." 4.2 |
| .\} |
| otherwise, |
| \fIrefs/remotes/<refname>/HEAD\fR |
| if it exists\&. |
| .sp |
| \fBHEAD\fR |
| names the commit on which you based the changes in the working tree\&. |
| \fBFETCH_HEAD\fR |
| records the branch which you fetched from a remote repository with your last |
| \fBgit fetch\fR |
| invocation\&. |
| \fBORIG_HEAD\fR |
| is created by commands that move your |
| \fBHEAD\fR |
| in a drastic way, to record the position of the |
| \fBHEAD\fR |
| before their operation, so that you can easily change the tip of the branch back to the state before you ran them\&. |
| \fBMERGE_HEAD\fR |
| records the commit(s) which you are merging into your branch when you run |
| \fBgit merge\fR\&. |
| \fBCHERRY_PICK_HEAD\fR |
| records the commit which you are cherry\-picking when you run |
| \fBgit cherry\-pick\fR\&. |
| .sp |
| Note that any of the |
| \fIrefs/*\fR |
| cases above may come either from the |
| \fB$GIT_DIR/refs\fR |
| directory or from the |
| \fB$GIT_DIR/packed\-refs\fR |
| file\&. While the ref name encoding is unspecified, UTF\-8 is preferred as some output processing may assume ref names in UTF\-8\&. |
| .RE |
| .RE |
| .PP |
| \fI@\fR |
| .RS 4 |
| \fI@\fR |
| alone is a shortcut for |
| \fBHEAD\fR\&. |
| .RE |
| .PP |
| \fI[<refname>]@{<date>}\fR, e\&.g\&. \fImaster@{yesterday}\fR, \fIHEAD@{5 minutes ago}\fR |
| .RS 4 |
| A ref followed by the suffix |
| \fI@\fR |
| with a date specification enclosed in a brace pair (e\&.g\&. |
| \fI{yesterday}\fR, |
| \fI{1 month 2 weeks 3 days 1 hour 1 second ago}\fR |
| or |
| \fI{1979\-02\-26 18:30:00}\fR) specifies the value of the ref at a prior point in time\&. This suffix may only be used immediately following a ref name and the ref must have an existing log (\fI$GIT_DIR/logs/<ref>\fR)\&. Note that this looks up the state of your |
| \fBlocal\fR |
| ref at a given time; e\&.g\&., what was in your local |
| \fImaster\fR |
| branch last week\&. If you want to look at commits made during certain times, see |
| \fB\-\-since\fR |
| and |
| \fB\-\-until\fR\&. |
| .RE |
| .PP |
| \fI<refname>@{<n>}\fR, e\&.g\&. \fImaster@{1}\fR |
| .RS 4 |
| A ref followed by the suffix |
| \fI@\fR |
| with an ordinal specification enclosed in a brace pair (e\&.g\&. |
| \fI{1}\fR, |
| \fI{15}\fR) specifies the n\-th prior value of that ref\&. For example |
| \fImaster@{1}\fR |
| is the immediate prior value of |
| \fImaster\fR |
| while |
| \fImaster@{5}\fR |
| is the 5th prior value of |
| \fImaster\fR\&. This suffix may only be used immediately following a ref name and the ref must have an existing log (\fI$GIT_DIR/logs/<refname>\fR)\&. |
| .RE |
| .PP |
| \fI@{<n>}\fR, e\&.g\&. \fI@{1}\fR |
| .RS 4 |
| You can use the |
| \fI@\fR |
| construct with an empty ref part to get at a reflog entry of the current branch\&. For example, if you are on branch |
| \fIblabla\fR |
| then |
| \fI@{1}\fR |
| means the same as |
| \fIblabla@{1}\fR\&. |
| .RE |
| .PP |
| \fI@{\-<n>}\fR, e\&.g\&. \fI@{\-1}\fR |
| .RS 4 |
| The construct |
| \fI@{\-<n>}\fR |
| means the <n>th branch/commit checked out before the current one\&. |
| .RE |
| .PP |
| \fI[<branchname>]@{upstream}\fR, e\&.g\&. \fImaster@{upstream}\fR, \fI@{u}\fR |
| .RS 4 |
| The suffix |
| \fI@{upstream}\fR |
| to a branchname (short form |
| \fI<branchname>@{u}\fR) refers to the branch that the branch specified by branchname is set to build on top of (configured with |
| \fBbranch\&.<name>\&.remote\fR |
| and |
| \fBbranch\&.<name>\&.merge\fR)\&. A missing branchname defaults to the current one\&. These suffixes are also accepted when spelled in uppercase, and they mean the same thing no matter the case\&. |
| .RE |
| .PP |
| \fI[<branchname>]@{push}\fR, e\&.g\&. \fImaster@{push}\fR, \fI@{push}\fR |
| .RS 4 |
| The suffix |
| \fI@{push}\fR |
| reports the branch "where we would push to" if |
| \fBgit push\fR |
| were run while |
| \fBbranchname\fR |
| was checked out (or the current |
| \fBHEAD\fR |
| if no branchname is specified)\&. Since our push destination is in a remote repository, of course, we report the local tracking branch that corresponds to that branch (i\&.e\&., something in |
| \fBrefs/remotes/\fR)\&. |
| .sp |
| Here\(cqs an example to make it more clear: |
| .sp |
| .if n \{\ |
| .RS 4 |
| .\} |
| .nf |
| $ git config push\&.default current |
| $ git config remote\&.pushdefault myfork |
| $ git switch \-c mybranch origin/master |
| |
| $ git rev\-parse \-\-symbolic\-full\-name @{upstream} |
| refs/remotes/origin/master |
| |
| $ git rev\-parse \-\-symbolic\-full\-name @{push} |
| refs/remotes/myfork/mybranch |
| .fi |
| .if n \{\ |
| .RE |
| .\} |
| .sp |
| Note in the example that we set up a triangular workflow, where we pull from one location and push to another\&. In a non\-triangular workflow, |
| \fI@{push}\fR |
| is the same as |
| \fI@{upstream}\fR, and there is no need for it\&. |
| .sp |
| This suffix is also accepted when spelled in uppercase, and means the same thing no matter the case\&. |
| .RE |
| .PP |
| \fI<rev>^[<n>]\fR, e\&.g\&. \fIHEAD^, v1\&.5\&.1^0\fR |
| .RS 4 |
| A suffix |
| \fI^\fR |
| to a revision parameter means the first parent of that commit object\&. |
| \fI^<n>\fR |
| means the <n>th parent (i\&.e\&. |
| \fI<rev>^\fR |
| is equivalent to |
| \fI<rev>^1\fR)\&. As a special rule, |
| \fI<rev>^0\fR |
| means the commit itself and is used when |
| \fI<rev>\fR |
| is the object name of a tag object that refers to a commit object\&. |
| .RE |
| .PP |
| \fI<rev>~[<n>]\fR, e\&.g\&. \fIHEAD~, master~3\fR |
| .RS 4 |
| A suffix |
| \fI~\fR |
| to a revision parameter means the first parent of that commit object\&. A suffix |
| \fI~<n>\fR |
| to a revision parameter means the commit object that is the <n>th generation ancestor of the named commit object, following only the first parents\&. I\&.e\&. |
| \fI<rev>~3\fR |
| is equivalent to |
| \fI<rev>^^^\fR |
| which is equivalent to |
| \fI<rev>^1^1^1\fR\&. See below for an illustration of the usage of this form\&. |
| .RE |
| .PP |
| \fI<rev>^{<type>}\fR, e\&.g\&. \fIv0\&.99\&.8^{commit}\fR |
| .RS 4 |
| A suffix |
| \fI^\fR |
| followed by an object type name enclosed in brace pair means dereference the object at |
| \fI<rev>\fR |
| recursively until an object of type |
| \fI<type>\fR |
| is found or the object cannot be dereferenced anymore (in which case, barf)\&. For example, if |
| \fI<rev>\fR |
| is a commit\-ish, |
| \fI<rev>^{commit}\fR |
| describes the corresponding commit object\&. Similarly, if |
| \fI<rev>\fR |
| is a tree\-ish, |
| \fI<rev>^{tree}\fR |
| describes the corresponding tree object\&. |
| \fI<rev>^0\fR |
| is a short\-hand for |
| \fI<rev>^{commit}\fR\&. |
| .sp |
| \fI<rev>^{object}\fR |
| can be used to make sure |
| \fI<rev>\fR |
| names an object that exists, without requiring |
| \fI<rev>\fR |
| to be a tag, and without dereferencing |
| \fI<rev>\fR; because a tag is already an object, it does not have to be dereferenced even once to get to an object\&. |
| .sp |
| \fI<rev>^{tag}\fR |
| can be used to ensure that |
| \fI<rev>\fR |
| identifies an existing tag object\&. |
| .RE |
| .PP |
| \fI<rev>^{}\fR, e\&.g\&. \fIv0\&.99\&.8^{}\fR |
| .RS 4 |
| A suffix |
| \fI^\fR |
| followed by an empty brace pair means the object could be a tag, and dereference the tag recursively until a non\-tag object is found\&. |
| .RE |
| .PP |
| \fI<rev>^{/<text>}\fR, e\&.g\&. \fIHEAD^{/fix nasty bug}\fR |
| .RS 4 |
| A suffix |
| \fI^\fR |
| to a revision parameter, followed by a brace pair that contains a text led by a slash, is the same as the |
| \fI:/fix nasty bug\fR |
| syntax below except that it returns the youngest matching commit which is reachable from the |
| \fI<rev>\fR |
| before |
| \fI^\fR\&. |
| .RE |
| .PP |
| \fI:/<text>\fR, e\&.g\&. \fI:/fix nasty bug\fR |
| .RS 4 |
| A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression\&. This name returns the youngest matching commit which is reachable from any ref, including HEAD\&. The regular expression can match any part of the commit message\&. To match messages starting with a string, one can use e\&.g\&. |
| \fI:/^foo\fR\&. The special sequence |
| \fI:/!\fR |
| is reserved for modifiers to what is matched\&. |
| \fI:/!\-foo\fR |
| performs a negative match, while |
| \fI:/!!foo\fR |
| matches a literal |
| \fI!\fR |
| character, followed by |
| \fIfoo\fR\&. Any other sequence beginning with |
| \fI:/!\fR |
| is reserved for now\&. Depending on the given text, the shell\(cqs word splitting rules might require additional quoting\&. |
| .RE |
| .PP |
| \fI<rev>:<path>\fR, e\&.g\&. \fIHEAD:README\fR, \fImaster:\&./README\fR |
| .RS 4 |
| A suffix |
| \fI:\fR |
| followed by a path names the blob or tree at the given path in the tree\-ish object named by the part before the colon\&. A path starting with |
| \fI\&./\fR |
| or |
| \fI\&.\&./\fR |
| is relative to the current working directory\&. The given path will be converted to be relative to the working tree\(cqs root directory\&. This is most useful to address a blob or tree from a commit or tree that has the same tree structure as the working tree\&. |
| .RE |
| .PP |
| \fI:[<n>:]<path>\fR, e\&.g\&. \fI:0:README\fR, \fI:README\fR |
| .RS 4 |
| A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path, names a blob object in the index at the given path\&. A missing stage number (and the colon that follows it) names a stage 0 entry\&. During a merge, stage 1 is the common ancestor, stage 2 is the target branch\(cqs version (typically the current branch), and stage 3 is the version from the branch which is being merged\&. |
| .RE |
| .sp |
| Here is an illustration, by Jon Loeliger\&. Both commit nodes B and C are parents of commit node A\&. Parent commits are ordered left\-to\-right\&. |
| .sp |
| .if n \{\ |
| .RS 4 |
| .\} |
| .nf |
| G H I J |
| \e / \e / |
| D E F |
| \e | / \e |
| \e | / | |
| \e|/ | |
| B C |
| \e / |
| \e / |
| A |
| .fi |
| .if n \{\ |
| .RE |
| .\} |
| .sp |
| .if n \{\ |
| .RS 4 |
| .\} |
| .nf |
| A = = A^0 |
| B = A^ = A^1 = A~1 |
| C = = A^2 |
| D = A^^ = A^1^1 = A~2 |
| E = B^2 = A^^2 |
| F = B^3 = A^^3 |
| G = A^^^ = A^1^1^1 = A~3 |
| H = D^2 = B^^2 = A^^^2 = A~2^2 |
| I = F^ = B^3^ = A^^3^ |
| J = F^2 = B^3^2 = A^^3^2 |
| .fi |
| .if n \{\ |
| .RE |
| .\} |
| .SH "SPECIFYING RANGES" |
| .sp |
| History traversing commands such as \fBgit log\fR operate on a set of commits, not just a single commit\&. |
| .sp |
| For these commands, specifying a single revision, using the notation described in the previous section, means the set of commits \fBreachable\fR from the given commit\&. |
| .sp |
| A commit\(cqs reachable set is the commit itself and the commits in its ancestry chain\&. |
| .SS "Commit Exclusions" |
| .PP |
| \fI^<rev>\fR (caret) Notation |
| .RS 4 |
| To exclude commits reachable from a commit, a prefix |
| \fI^\fR |
| notation is used\&. E\&.g\&. |
| \fI^r1 r2\fR |
| means commits reachable from |
| \fIr2\fR |
| but exclude the ones reachable from |
| \fIr1\fR |
| (i\&.e\&. |
| \fIr1\fR |
| and its ancestors)\&. |
| .RE |
| .SS "Dotted Range Notations" |
| .PP |
| The \fI\&.\&.\fR (two\-dot) Range Notation |
| .RS 4 |
| The |
| \fI^r1 r2\fR |
| set operation appears so often that there is a shorthand for it\&. When you have two commits |
| \fIr1\fR |
| and |
| \fIr2\fR |
| (named according to the syntax explained in SPECIFYING REVISIONS above), you can ask for commits that are reachable from r2 excluding those that are reachable from r1 by |
| \fI^r1 r2\fR |
| and it can be written as |
| \fIr1\&.\&.r2\fR\&. |
| .RE |
| .PP |
| The \fI\&...\fR (three\-dot) Symmetric Difference Notation |
| .RS 4 |
| A similar notation |
| \fIr1\&.\&.\&.r2\fR |
| is called symmetric difference of |
| \fIr1\fR |
| and |
| \fIr2\fR |
| and is defined as |
| \fIr1 r2 \-\-not $(git merge\-base \-\-all r1 r2)\fR\&. It is the set of commits that are reachable from either one of |
| \fIr1\fR |
| (left side) or |
| \fIr2\fR |
| (right side) but not from both\&. |
| .RE |
| .sp |
| In these two shorthand notations, you can omit one end and let it default to HEAD\&. For example, \fIorigin\&.\&.\fR is a shorthand for \fIorigin\&.\&.HEAD\fR and asks "What did I do since I forked from the origin branch?" Similarly, \fI\&.\&.origin\fR is a shorthand for \fIHEAD\&.\&.origin\fR and asks "What did the origin do since I forked from them?" Note that \fI\&.\&.\fR would mean \fIHEAD\&.\&.HEAD\fR which is an empty range that is both reachable and unreachable from HEAD\&. |
| .SS "Other <rev>^ Parent Shorthand Notations" |
| .sp |
| Three other shorthands exist, particularly useful for merge commits, for naming a set that is formed by a commit and its parent commits\&. |
| .sp |
| The \fIr1^@\fR notation means all parents of \fIr1\fR\&. |
| .sp |
| The \fIr1^!\fR notation includes commit \fIr1\fR but excludes all of its parents\&. By itself, this notation denotes the single commit \fIr1\fR\&. |
| .sp |
| The \fI<rev>^\-[<n>]\fR notation includes \fI<rev>\fR but excludes the <n>th parent (i\&.e\&. a shorthand for \fI<rev>^<n>\&.\&.<rev>\fR), with \fI<n>\fR = 1 if not given\&. This is typically useful for merge commits where you can just pass \fI<commit>^\-\fR to get all the commits in the branch that was merged in merge commit \fI<commit>\fR (including \fI<commit>\fR itself)\&. |
| .sp |
| While \fI<rev>^<n>\fR was about specifying a single commit parent, these three notations also consider its parents\&. For example you can say \fIHEAD^2^@\fR, however you cannot say \fIHEAD^@^2\fR\&. |
| .SH "REVISION RANGE SUMMARY" |
| .PP |
| \fI<rev>\fR |
| .RS 4 |
| Include commits that are reachable from <rev> (i\&.e\&. <rev> and its ancestors)\&. |
| .RE |
| .PP |
| \fI^<rev>\fR |
| .RS 4 |
| Exclude commits that are reachable from <rev> (i\&.e\&. <rev> and its ancestors)\&. |
| .RE |
| .PP |
| \fI<rev1>\&.\&.<rev2>\fR |
| .RS 4 |
| 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 |
| \fBHEAD\fR\&. |
| .RE |
| .PP |
| \fI<rev1>\&.\&.\&.<rev2>\fR |
| .RS 4 |
| 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 |
| \fBHEAD\fR\&. |
| .RE |
| .PP |
| \fI<rev>^@\fR, e\&.g\&. \fIHEAD^@\fR |
| .RS 4 |
| A suffix |
| \fI^\fR |
| followed by an at sign is the same as listing all parents of |
| \fI<rev>\fR |
| (meaning, include anything reachable from its parents, but not the commit itself)\&. |
| .RE |
| .PP |
| \fI<rev>^!\fR, e\&.g\&. \fIHEAD^!\fR |
| .RS 4 |
| A suffix |
| \fI^\fR |
| followed by an exclamation mark is the same as giving commit |
| \fI<rev>\fR |
| and then all its parents prefixed with |
| \fI^\fR |
| to exclude them (and their ancestors)\&. |
| .RE |
| .PP |
| \fI<rev>^\-<n>\fR, e\&.g\&. \fIHEAD^\-, HEAD^\-2\fR |
| .RS 4 |
| Equivalent to |
| \fI<rev>^<n>\&.\&.<rev>\fR, with |
| \fI<n>\fR |
| = 1 if not given\&. |
| .RE |
| .sp |
| Here are a handful of examples using the Loeliger illustration above, with each step in the notation\(cqs expansion and selection carefully spelt out: |
| .sp |
| .if n \{\ |
| .RS 4 |
| .\} |
| .nf |
| Args Expanded arguments Selected commits |
| D G H D |
| D F G H I J D F |
| ^G D H D |
| ^D B E I J F B |
| ^D B C E I J F B C |
| C I J F C |
| B\&.\&.C = ^B C C |
| B\&.\&.\&.C = B ^F C G H D E B C |
| B^\- = B^\&.\&.B |
| = ^B^1 B E I J F B |
| C^@ = C^1 |
| = F I J F |
| B^@ = B^1 B^2 B^3 |
| = D E F D G H E F I J |
| C^! = C ^C^@ |
| = C ^C^1 |
| = C ^F C |
| B^! = B ^B^@ |
| = B ^B^1 ^B^2 ^B^3 |
| = B ^D ^E ^F B |
| F^! D = F ^I ^J D G H D F |
| .fi |
| .if n \{\ |
| .RE |
| .\} |
| .SH "SEE ALSO" |
| .sp |
| \fBgit-rev-parse\fR(1) |
| .SH "GIT" |
| .sp |
| Part of the \fBgit\fR(1) suite |