@@ -65,7 +65,7 @@ some output processing may assume ref names in UTF-8.
65
65
'@'::
66
66
'@' alone is a shortcut for `HEAD`.
67
67
68
- '<refname>@{<date>}', e.g. 'master@\{yesterday\}', 'HEAD@{5 minutes ago}'::
68
+ '[ <refname>] @{<date>}', e.g. 'master@\{yesterday\}', 'HEAD@{5 minutes ago}'::
69
69
A ref followed by the suffix '@' with a date specification
70
70
enclosed in a brace
71
71
pair (e.g. '\{yesterday\}', '{1 month 2 weeks 3 days 1 hour 1
@@ -95,15 +95,15 @@ some output processing may assume ref names in UTF-8.
95
95
The construct '@{-<n>}' means the <n>th branch/commit checked out
96
96
before the current one.
97
97
98
- '<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
98
+ '[ <branchname>] @\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
99
99
The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')
100
100
refers to the branch that the branch specified by branchname is set to build on
101
101
top of (configured with `branch.<name>.remote` and
102
102
`branch.<name>.merge`). A missing branchname defaults to the
103
103
current one. These suffixes are also accepted when spelled in uppercase, and
104
104
they mean the same thing no matter the case.
105
105
106
- '<branchname>@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
106
+ '[ <branchname>] @\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
107
107
The suffix '@\{push}' reports the branch "where we would push to" if
108
108
`git push` were run while `branchname` was checked out (or the current
109
109
`HEAD` if no branchname is specified). Since our push destination is
@@ -131,15 +131,17 @@ from one location and push to another. In a non-triangular workflow,
131
131
This suffix is also accepted when spelled in uppercase, and means the same
132
132
thing no matter the case.
133
133
134
- '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
134
+ '<rev>{caret}[<n>] ', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
135
135
A suffix '{caret}' to a revision parameter means the first parent of
136
136
that commit object. '{caret}<n>' means the <n>th parent (i.e.
137
137
'<rev>{caret}'
138
138
is equivalent to '<rev>{caret}1'). As a special rule,
139
139
'<rev>{caret}0' means the commit itself and is used when '<rev>' is the
140
140
object name of a tag object that refers to a commit object.
141
141
142
- '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
142
+ '<rev>{tilde}[<n>]', e.g. 'HEAD{tilde}, master{tilde}3'::
143
+ A suffix '{tilde}' to a revision parameter means the first parent of
144
+ that commit object.
143
145
A suffix '{tilde}<n>' to a revision parameter means the commit
144
146
object that is the <n>th generation ancestor of the named
145
147
commit object, following only the first parents. I.e. '<rev>{tilde}3' is
@@ -159,12 +161,12 @@ thing no matter the case.
159
161
'<rev>{caret}0'
160
162
is a short-hand for '<rev>{caret}\{commit\}'.
161
163
+
162
- 'rev{caret}\{object\}' can be used to make sure 'rev' names an
163
- object that exists, without requiring 'rev' to be a tag, and
164
- without dereferencing 'rev'; because a tag is already an object,
164
+ '< rev> {caret}\{object\}' can be used to make sure '< rev> ' names an
165
+ object that exists, without requiring '< rev> ' to be a tag, and
166
+ without dereferencing '< rev> '; because a tag is already an object,
165
167
it does not have to be dereferenced even once to get to an object.
166
168
+
167
- 'rev{caret}\{tag\}' can be used to ensure that 'rev' identifies an
169
+ '< rev> {caret}\{tag\}' can be used to ensure that '< rev> ' identifies an
168
170
existing tag object.
169
171
170
172
'<rev>{caret}{}', e.g. 'v0.99.8{caret}{}'::
@@ -194,19 +196,16 @@ existing tag object.
194
196
Depending on the given text, the shell's word splitting rules might
195
197
require additional quoting.
196
198
197
- '<rev>:<path>', e.g. 'HEAD:README', ':README', ' master:./README'::
199
+ '<rev>:<path>', e.g. 'HEAD:README', 'master:./README'::
198
200
A suffix ':' followed by a path names the blob or tree
199
201
at the given path in the tree-ish object named by the part
200
202
before the colon.
201
- ':path' (with an empty part before the colon)
202
- is a special case of the syntax described next: content
203
- recorded in the index at the given path.
204
203
A path starting with './' or '../' is relative to the current working directory.
205
204
The given path will be converted to be relative to the working tree's root directory.
206
205
This is most useful to address a blob or tree from a commit or tree that has
207
206
the same tree structure as the working tree.
208
207
209
- ':<n>:<path>', e.g. ':0:README', ':README'::
208
+ ':[ <n>:] <path>', e.g. ':0:README', ':README'::
210
209
A colon, optionally followed by a stage number (0 to 3) and a
211
210
colon, followed by a path, names a blob object in the
212
211
index at the given path. A missing stage number (and the colon
@@ -302,7 +301,7 @@ The 'r1{caret}@' notation means all parents of 'r1'.
302
301
The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
303
302
By itself, this notation denotes the single commit 'r1'.
304
303
305
- The '<rev>{caret}-<n>' notation includes '<rev>' but excludes the <n>th
304
+ The '<rev>{caret}-[ <n>] ' notation includes '<rev>' but excludes the <n>th
306
305
parent (i.e. a shorthand for '<rev>{caret}<n>..<rev>'), with '<n>' = 1 if
307
306
not given. This is typically useful for merge commits where you
308
307
can just pass '<commit>{caret}-' to get all the commits in the branch
0 commit comments