NAME
git-rev-parse - Pick out and massage parameters
SYNOPSIS
git-rev-parse [ --option ] <args>
DESCRIPTION
Many git porcelainish commands take mixture of
flags (i.e. parameters that begin with a dash -) and
parameters meant for underlying git-rev-list command they use
internally and flags and parameters for other commands they use as
the downstream of git-rev-list. This command is used to distinguish
between them.
OPTIONS
- --revs-only
- Do not output flags and parameters not meant for git-rev-list
command.
- --no-revs
- Do not output flags and parameters meant for git-rev-list
command.
- --flags
- Do not output non-flag parameters.
- --no-flags
- Do not output flag parameters.
- --default <arg>
- If there is no parameter given by the user, use <arg>
instead.
- --verify
- The parameter given must be usable as a single, valid object
name. Otherwise barf and abort.
- --sq
- Usually the output is made one line per flag and parameter.
This option makes output a single line, properly quoted for
consumption by shell. Useful when you expect your parameter to
contain whitespaces and newlines (e.g. when using pickaxe -S with
git-diff-*).
- --not
- When showing object names, prefix them with ^ and strip
^ prefix from the object names that already have one.
- --symbolic
- Usually the object names are output in SHA1 form (with possible
^ prefix); this option makes them output in a form as close
to the original input as possible.
- --all
- Show all refs found in $GIT_DIR/refs.
- --branches
- Show branch refs found in $GIT_DIR/refs/heads.
- --tags
- Show tag refs found in $GIT_DIR/refs/tags.
- --remotes
- Show tag refs found in $GIT_DIR/refs/remotes.
- --show-prefix
- When the command is invoked from a subdirectory, show the path
of the current directory relative to the top-level directory.
- --show-cdup
- When the command is invoked from a subdirectory, show the path
of the top-level directory relative to the current directory
(typically a sequence of "../", or an empty string).
- --git-dir
- Show $GIT_DIR if defined else show the path to the .git
directory.
- --short, --short=number
- Instead of outputting the full SHA1 values of object names try
to abbreviate them to a shorter unique name. When no length is
specified 7 is used. The minimum length is 4.
- --since=datestring, --after=datestring
- Parses the date string, and outputs corresponding --max-age=
parameter for git-rev-list command.
- --until=datestring, --before=datestring
- Parses the date string, and outputs corresponding --min-age=
parameter for git-rev-list command.
- <args>Flags and parameters to be parsed.
SPECIFYING REVISIONS
A revision parameter typically, but
not necessarily, names a commit object. They use what is called an
extended SHA1 syntax. Here are various ways to spell object
names. The ones listed near the end of this list are to name trees
and blobs contained in a commit.
- *
- The full SHA1 object name (40-byte hexadecimal string), or a
substring of such that is unique within the repository. E.g.
dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the
same commit object if there are no other object in your repository
whose object name starts with dae86e.
- *
- An output from git-describe; i.e. a closest tag, followed by a
dash, a g, and an abbreviated object name.
- *
- A symbolic ref name. E.g. master typically means the
commit object referenced by $GIT_DIR/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 first
match in the following rules:
-
- 1.
- if $GIT_DIR/<name> exists, that is what you mean (this is
usually useful only for HEAD, FETCH_HEAD and MERGE_HEAD);
- 2.
- otherwise, $GIT_DIR/refs/<name> if exists;
- 3.
- otherwise, $GIT_DIR/refs/tags/<name> if exists;
- 4.
- otherwise, $GIT_DIR/refs/heads/<name> if exists;
- 5.
- otherwise, $GIT_DIR/refs/remotes/<name> if exists;
- 6.
- otherwise, $GIT_DIR/refs/remotes/<name>/HEAD if
exists.
- *
- A ref followed by the suffix @ with a date specification
enclosed in a brace pair (e.g. {yesterday}, {1 month 2
weeks 3 days 1 hour 1 second ago} or {1979-02-26
18:30:00}) to specify 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 ($GIT_DIR/logs/<ref>).
- *
- A suffix ^ to a revision parameter means the first
parent of that commit object. ^<n> means the
<n>th parent (i.e. rev^ is equivalent to
rev^1). As a special rule, rev^0 means the commit
itself and is used when rev is the object name of a tag
object that refers to a commit object.
- *
- A suffix ~<n> to a revision parameter means the
commit object that is the <n>th generation grand-parent of
the named commit object, following only the first parent. I.e.
rev~3 is equivalent to rev^^^ which is equivalent to rev^1^1^1. See
below for a illustration of the usage of this form.
- *
- A suffix ^ followed by an object type name enclosed in
brace pair (e.g. v0.99.8^{commit}) 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^0 introduced earlier is a short-hand for rev^{commit}.
- *
- A suffix ^ followed by an empty brace pair (e.g.
v0.99.8^{}) means the object could be a tag, and dereference the
tag recursively until a non-tag object is found.
- *
- A suffix : followed by a path; this names the blob or
tree at the given path in the tree-ish object named by the part
before the colon.
- *
- A colon, optionally followed by a stage number (0 to 3) and a
colon, followed by a path; this names a blob object in the index at
the given path. Missing stage number (and the colon that follows
it) names an stage 0 entry. Here is an illustration, by Jon
Loeliger. Both node B and C are a commit parents of commit node A.
Parent commits are ordered left-to-right.
G H I J
\ / \ /
D E F
\ | / \ | / |
\|/ |
B C
\ /
\ /
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2 = 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
SPECIFYING RANGES
History traversing commands such as
git-log operate on a set of commits, not just a single commit. To
these commands, specifying a single revision with the notation
described in the previous section means the set of commits
reachable from that commit, following the commit ancestry chain.
To exclude commits reachable from a commit, a prefix ^ notation
is used. E.g. "^r1 r2" means commits reachable from r2 but exclude
the ones reachable from r1.
This set operation appears so often that there is a shorthand
for it. "r1..r2" is equivalent to "^r1 r2". It is the difference of
two sets (subtract the set of commits reachable from r1 from the
set of commits reachable from r2).
A similar notation "r1...r2" is called symmetric difference of
r1 and r2 and is defined as "r1 r2 --not $(git-merge-base --all r1
r2)". It it the set of commits that are reachable from either one
of r1 or r2 but not from both.
Two other shorthands for naming a set that is formed by a commit
and its parent commits exists. r1^@ notation means all parents of
r1. r1^! includes commit r1 but excludes its all parents.
Here are a handful examples:
D A B D
D F A B C D F
^A G B D
^A F B C F
G...I C D F G I
^B G I C D F G I
F^@ A B C
F^! H D F H
AUTHOR
Written by Linus Torvalds <torvalds@osdl.org> and Junio C
Hamano <junkio@cox.net>
DOCUMENTATION
Documentation by Junio C Hamano and the
git-list <git@vger.kernel.org>.
GIT
Part of the (7) suite