4
4
A revision parameter '<rev>' typically, but not necessarily, names a
5
commit object. It uses what is called an 'extended SHA1'
5
commit object. It uses what is called an 'extended SHA-1'
6
6
syntax. Here are various ways to spell object names. The
7
7
ones listed near the end of this list name trees and
8
8
blobs contained in a commit.
10
10
'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
11
The full SHA1 object name (40-byte hexadecimal string), or
11
The full SHA-1 object name (40-byte hexadecimal string), or
12
12
a leading substring that is unique within the repository.
13
13
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
14
14
name the same commit object if there is no other object in
23
23
A symbolic ref name. E.g. 'master' typically means the commit
24
24
object referenced by 'refs/heads/master'. If you
25
25
happen to have both 'heads/master' and 'tags/master', you can
26
explicitly say 'heads/master' to tell git which one you mean.
27
When ambiguous, a '<name>' is disambiguated by taking the
26
explicitly say 'heads/master' to tell Git which one you mean.
27
When ambiguous, a '<refname>' is disambiguated by taking the
28
28
first match in the following rules:
30
. If '$GIT_DIR/<name>' exists, that is what you mean (this is usually
30
. If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
31
31
useful only for 'HEAD', 'FETCH_HEAD', 'ORIG_HEAD', 'MERGE_HEAD'
32
32
and 'CHERRY_PICK_HEAD');
34
. otherwise, 'refs/<name>' if it exists;
34
. otherwise, 'refs/<refname>' if it exists;
36
36
. otherwise, 'refs/tags/<refname>' if it exists;
38
. otherwise, 'refs/heads/<name>' if it exists;
40
. otherwise, 'refs/remotes/<name>' if it exists;
42
. otherwise, 'refs/remotes/<name>/HEAD' if it exists.
38
. otherwise, 'refs/heads/<refname>' if it exists;
40
. otherwise, 'refs/remotes/<refname>' if it exists;
42
. otherwise, 'refs/remotes/<refname>/HEAD' if it exists.
44
44
'HEAD' names the commit on which you based the changes in the working tree.
45
45
'FETCH_HEAD' records the branch which you fetched from a remote repository
56
56
Note that any of the 'refs/*' cases above may come either from
57
57
the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
58
While the ref name encoding is unspecified, UTF-8 is preferred as
59
some output processing may assume ref names in UTF-8.
59
61
'<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}'::
60
62
A ref followed by the suffix '@' with a date specification
86
88
The construct '@\{-<n>\}' means the <n>th branch checked out
87
89
before the current one.
89
'<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
90
The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to
91
the branch the ref is set to build on top of. A missing ref defaults
92
to the current branch.
91
'<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
92
The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')
93
refers to the branch that the branch specified by branchname is set to build on
94
top of. A missing branchname defaults to the current one.
94
96
'<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
95
97
A suffix '{caret}' to a revision parameter means the first parent of
114
116
object of that type is found or the object cannot be
115
117
dereferenced anymore (in which case, barf). '<rev>{caret}0'
116
118
is a short-hand for '<rev>{caret}\{commit\}'.
120
'rev{caret}\{object\}' can be used to make sure 'rev' names an
121
object that exists, without requiring 'rev' to be a tag, and
122
without dereferencing 'rev'; because a tag is already an object,
123
it does not have to be dereferenced even once to get to an object.
118
125
'<rev>{caret}\{\}', e.g. 'v0.99.8{caret}\{\}'::
119
126
A suffix '{caret}' followed by an empty brace pair
213
220
It is the set of commits that are reachable from either one of
214
221
'r1' or 'r2' but not from both.
223
In these two shorthands, you can omit one end and let it default to HEAD.
224
For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What
225
did I do since I forked from the origin branch?" Similarly, '..origin'
226
is a shorthand for 'HEAD..origin' and asks "What did the origin do since
227
I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an
228
empty range that is both reachable and unreachable from HEAD.
216
230
Two other shorthands for naming a set that is formed by a commit
217
231
and its parent commits exist. The 'r1{caret}@' notation means all
218
232
parents of 'r1'. 'r1{caret}!' includes commit 'r1' but excludes
219
233
all of its parents.
238
Include commits that are reachable from (i.e. ancestors of)
242
Exclude commits that are reachable from (i.e. ancestors of)
246
Include commits that are reachable from <rev2> but exclude
247
those that are reachable from <rev1>. When either <rev1> or
248
<rev2> is omitted, it defaults to 'HEAD'.
251
Include commits that are reachable from either <rev1> or
252
<rev2> but exclude those that are reachable from both. When
253
either <rev1> or <rev2> is omitted, it defaults to 'HEAD'.
255
'<rev>{caret}@', e.g. 'HEAD{caret}@'::
256
A suffix '{caret}' followed by an at sign is the same as listing
257
all parents of '<rev>' (meaning, include anything reachable from
258
its parents, but not the commit itself).
260
'<rev>{caret}!', e.g. 'HEAD{caret}!'::
261
A suffix '{caret}' followed by an exclamation mark is the same
262
as giving commit '<rev>' and then all its parents prefixed with
263
'{caret}' to exclude them (and their ancestors).
221
265
Here are a handful of examples:
227
272
B...C G H D E B C
228
273
^D B C E I J F B C
added
removed
Documentation/revisions.txt
