6 git-rev-parse - Pick out and massage parameters
12 'git rev-parse' [<options>] <arg>...
17 Many Git porcelainish commands take a mixture of flags
18 (i.e. parameters that begin with a dash '-') and parameters
19 meant for the underlying 'git rev-list' command they use internally
20 and flags and parameters for the other commands they use
21 downstream of 'git rev-list'. The primary purpose of this command
22 is to allow calling programs to distinguish between them. There are
23 a few other operation modes that have nothing to do with the above
24 "help parse command line options".
26 Unless otherwise specified, most of the options and operation modes
27 require you to run this command inside a git repository or a working
28 tree that is under the control of a git repository, and will give you
29 a fatal error otherwise.
38 Each of these options must appear first on the command line.
41 Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
42 The command in this mode can be used outside a repository or
43 a working tree controlled by a repository.
46 Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
47 section below). In contrast to the `--sq` option below, this
48 mode only does quoting. Nothing else is done to command input.
49 The command in this mode can be used outside a repository or
50 a working tree controlled by a repository.
52 Options for --parseopt
53 ~~~~~~~~~~~~~~~~~~~~~~
56 Only meaningful in `--parseopt` mode. Tells the option parser to echo
57 out the first `--` met instead of skipping it.
59 --stop-at-non-option::
60 Only meaningful in `--parseopt` mode. Lets the option parser stop at
61 the first non-option argument. This can be used to parse sub-commands
62 that take options themselves.
65 Only meaningful in `--parseopt` mode. Output the options in their
66 long form if available, and with their arguments stuck.
72 Do not output flags and parameters not meant for
73 'git rev-list' command.
76 Do not output flags and parameters meant for
77 'git rev-list' command.
80 Do not output non-flag parameters.
83 Do not output flag parameters.
89 If there is no parameter given by the user, use `<arg>`
93 Behave as if 'git rev-parse' was invoked from the `<arg>`
94 subdirectory of the working tree. Any relative filenames are
95 resolved as if they are prefixed by `<arg>` and will be printed
98 This can be used to convert arguments to a command run in a subdirectory
99 so that they can still be used after moving to the top-level of the
100 repository. For example:
103 prefix=$(git rev-parse --show-prefix)
104 cd "$(git rev-parse --show-toplevel)"
105 # rev-parse provides the -- needed for 'set'
106 eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
110 Verify that exactly one parameter is provided, and that it
111 can be turned into a raw 20-byte SHA-1 that can be used to
112 access the object database. If so, emit it to the standard
113 output; otherwise, error out.
115 If you want to make sure that the output actually names an object in
116 your object database and/or can be used as a specific type of object
117 you require, you can add the `^{type}` peeling operator to the parameter.
118 For example, `git rev-parse "$VAR^{commit}"` will make sure `$VAR`
119 names an existing object that is a commit-ish (i.e. a commit, or an
120 annotated tag that points at a commit). To make sure that `$VAR`
121 names an existing object of any type, `git rev-parse "$VAR^{object}"`
124 Note that if you are verifying a name from an untrusted source, it is
125 wise to use `--end-of-options` so that the name argument is not mistaken
130 Only meaningful in `--verify` mode. Do not output an error
131 message if the first argument is not a valid object name;
132 instead exit with non-zero status silently.
133 SHA-1s for valid object names are printed to stdout on success.
136 Usually the output is made one line per flag and
137 parameter. This option makes output a single line,
138 properly quoted for consumption by shell. Useful when
139 you expect your parameter to contain whitespaces and
140 newlines (e.g. when using pickaxe `-S` with
141 'git diff-{asterisk}'). In contrast to the `--sq-quote` option,
142 the command input is still interpreted as usual.
145 Same as `--verify` but shortens the object name to a unique
146 prefix with at least `length` characters. The minimum length
147 is 4, the default is the effective value of the `core.abbrev`
148 configuration variable (see linkgit:git-config[1]).
151 When showing object names, prefix them with '{caret}' and
152 strip '{caret}' prefix from the object names that already have
155 --abbrev-ref[=(strict|loose)]::
156 A non-ambiguous short name of the objects name.
157 The option core.warnAmbiguousRefs is used to select the strict
161 Usually the object names are output in SHA-1 form (with
162 possible '{caret}' prefix); this option makes them output in a
163 form as close to the original input as possible.
165 --symbolic-full-name::
166 This is similar to --symbolic, but it omits input that
167 are not refs (i.e. branch or tag names; or more
168 explicitly disambiguating "heads/master" form, when you
169 want to name the "master" branch when there is an
170 unfortunately named tag "master"), and shows them as full
171 refnames (e.g. "refs/heads/master").
173 --output-object-format=(sha1|sha256|storage)::
175 Allow oids to be input from any object format that the current
178 Specifying "sha1" translates if necessary and returns a sha1 oid.
180 Specifying "sha256" translates if necessary and returns a sha256 oid.
182 Specifying "storage" translates if necessary and returns an oid in
183 encoded in the storage hash algorithm.
189 Show all refs found in `refs/`.
191 --branches[=<pattern>]::
193 --remotes[=<pattern>]::
194 Show all branches, tags, or remote-tracking branches,
195 respectively (i.e., refs found in `refs/heads`,
196 `refs/tags`, or `refs/remotes`, respectively).
198 If a `pattern` is given, only refs matching the given shell glob are
199 shown. If the pattern does not contain a globbing character (`?`,
200 `*`, or `[`), it is turned into a prefix match by appending `/*`.
203 Show all refs matching the shell glob pattern `pattern`. If
204 the pattern does not start with `refs/`, this is automatically
205 prepended. If the pattern does not contain a globbing
206 character (`?`, `*`, or `[`), it is turned into a prefix
207 match by appending `/*`.
209 --exclude=<glob-pattern>::
210 Do not include refs matching '<glob-pattern>' that the next `--all`,
211 `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
212 consider. Repetitions of this option accumulate exclusion patterns
213 up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
214 `--glob` option (other options or arguments do not clear
215 accumulated patterns).
217 The patterns given should not begin with `refs/heads`, `refs/tags`, or
218 `refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
219 respectively, and they must begin with `refs/` when applied to `--glob`
220 or `--all`. If a trailing '/{asterisk}' is intended, it must be given
223 --exclude-hidden=(fetch|receive|uploadpack)::
224 Do not include refs that would be hidden by `git-fetch`,
225 `git-receive-pack` or `git-upload-pack` by consulting the appropriate
226 `fetch.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs`
227 configuration along with `transfer.hideRefs` (see
228 linkgit:git-config[1]). This option affects the next pseudo-ref option
229 `--all` or `--glob` and is cleared after processing them.
231 --disambiguate=<prefix>::
232 Show every object whose name begins with the given prefix.
233 The <prefix> must be at least 4 hexadecimal digits long to
234 avoid listing each and every object in the repository by
241 List the GIT_* environment variables that are local to the
242 repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR).
243 Only the names of the variables are listed, not their value,
244 even if they are set.
246 --path-format=(absolute|relative)::
247 Controls the behavior of certain other options. If specified as absolute, the
248 paths printed by those options will be absolute and canonical. If specified as
249 relative, the paths will be relative to the current working directory if that
250 is possible. The default is option specific.
252 This option may be specified multiple times and affects only the arguments that
253 follow it on the command line, either to the end of the command line or the next
254 instance of this option.
256 The following options are modified by `--path-format`:
259 Show `$GIT_DIR` if defined. Otherwise show the path to
260 the .git directory. The path shown, when relative, is
261 relative to the current working directory.
263 If `$GIT_DIR` is not defined and the current directory
264 is not detected to lie in a Git repository or work tree
265 print a message to stderr and exit with nonzero status.
268 Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`.
270 --resolve-git-dir <path>::
271 Check if <path> is a valid repository or a gitfile that
272 points at a valid repository, and print the location of the
273 repository. If <path> is a gitfile then the resolved path
274 to the real repository is printed.
277 Resolve "$GIT_DIR/<path>" and takes other path relocation
278 variables such as $GIT_OBJECT_DIRECTORY,
279 $GIT_INDEX_FILE... into account. For example, if
280 $GIT_OBJECT_DIRECTORY is set to /foo/bar then "git rev-parse
281 --git-path objects/abc" returns /foo/bar/abc.
284 Show the (by default, absolute) path of the top-level directory
285 of the working tree. If there is no working tree, report an error.
287 --show-superproject-working-tree::
288 Show the absolute path of the root of the superproject's
289 working tree (if exists) that uses the current repository as
290 its submodule. Outputs nothing if the current repository is
291 not used as a submodule by any project.
293 --shared-index-path::
294 Show the path to the shared index file in split index mode, or
295 empty if not in split-index mode.
297 The following options are unaffected by `--path-format`:
300 Like `--git-dir`, but its output is always the canonicalized
303 --is-inside-git-dir::
304 When the current working directory is below the repository
305 directory print "true", otherwise "false".
307 --is-inside-work-tree::
308 When the current working directory is inside the work tree of the
309 repository print "true", otherwise "false".
311 --is-bare-repository::
312 When the repository is bare print "true", otherwise "false".
314 --is-shallow-repository::
315 When the repository is shallow print "true", otherwise "false".
318 When the command is invoked from a subdirectory, show the
319 path of the top-level directory relative to the current
320 directory (typically a sequence of "../", or an empty string).
323 When the command is invoked from a subdirectory, show the
324 path of the current directory relative to the top-level
327 --show-object-format[=(storage|input|output)]::
328 Show the object format (hash algorithm) used for the repository
329 for storage inside the `.git` directory, input, or output. For
330 input, multiple algorithms may be printed, space-separated.
331 If not specified, the default is "storage".
334 Show the reference storage format used for the repository.
340 --since=<datestring>::
341 --after=<datestring>::
342 Parse the date string, and output the corresponding
343 --max-age= parameter for 'git rev-list'.
345 --until=<datestring>::
346 --before=<datestring>::
347 Parse the date string, and output the corresponding
348 --min-age= parameter for 'git rev-list'.
351 Flags and parameters to be parsed.
354 include::revisions.txt[]
359 In `--parseopt` mode, 'git rev-parse' helps massaging options to bring to shell
360 scripts the same facilities C builtins have. It works as an option normalizer
361 (e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
363 It takes on the standard input the specification of the options to parse and
364 understand, and echoes on the standard output a string suitable for `sh(1)` `eval`
365 to replace the arguments with normalized ones. In case of error, it outputs
366 usage on the standard error stream, and exits with code 129.
368 Note: Make sure you quote the result when passing it to `eval`. See
369 below for an example.
374 'git rev-parse --parseopt' input format is fully text based. It has two parts,
375 separated by a line that contains only `--`. The lines before the separator
376 (should be one or more) are used for the usage.
377 The lines after the separator describe the options.
379 Each line of options has this format:
382 <opt-spec><flags>*<arg-hint>? SP+ help LF
386 its format is the short option character, then the long option name
387 separated by a comma. Both parts are not required, though at least one
388 is necessary. May not contain any of the `<flags>` characters.
389 `h,help`, `dry-run` and `f` are examples of correct `<opt-spec>`.
392 `<flags>` are of `*`, `=`, `?` or `!`.
393 * Use `=` if the option takes an argument.
395 * Use `?` to mean that the option takes an optional argument. You
396 probably want to use the `--stuck-long` mode to be able to
397 unambiguously parse the optional argument.
399 * Use `*` to mean that this option should not be listed in the usage
400 generated for the `-h` argument. It's shown for `--help-all` as
401 documented in linkgit:gitcli[7].
403 * Use `!` to not make the corresponding negated long option available.
406 `<arg-hint>`, if specified, is used as a name of the argument in the
407 help output, for options that take arguments. `<arg-hint>` is
408 terminated by the first whitespace. It is customary to use a
409 dash to separate words in a multi-word argument hint.
411 The remainder of the line, after stripping the spaces, is used
412 as the help associated with the option.
414 Blank lines are ignored, and lines that don't match this specification are used
415 as option group headers (start the line with a space to create such
423 some-command [<options>] <args>...
425 some-command does foo and bar!
427 h,help! show the help
429 foo some nifty option --foo
430 bar= some cool option --bar with an argument
431 baz=arg another cool option --baz with a named argument
432 qux?path qux may take a path argument but has meaning by itself
434 An option group Header
435 C? option C with an optional argument"
437 eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
444 When `"$@"` is `-h` or `--help` in the above example, the following
445 usage text would be shown:
448 usage: some-command [<options>] <args>...
450 some-command does foo and bar!
452 -h, --help show the help
453 --[no-]foo some nifty option --foo
454 --[no-]bar ... some cool option --bar with an argument
455 --[no-]baz <arg> another cool option --baz with a named argument
456 --[no-]qux[=<path>] qux may take a path argument but has meaning by itself
458 An option group Header
459 -C[...] option C with an optional argument
465 In `--sq-quote` mode, 'git rev-parse' echoes on the standard output a
466 single line suitable for `sh(1)` `eval`. This line is made by
467 normalizing the arguments following `--sq-quote`. Nothing other than
468 quoting the arguments is done.
470 If you want command input to still be interpreted as usual by
471 'git rev-parse' before the output is shell quoted, see the `--sq`
478 $ cat >your-git-script.sh <<\EOF
480 args=$(git rev-parse --sq-quote "$@") # quote user-supplied arguments
481 command="git frotz -n24 $args" # and use it inside a handcrafted
486 $ sh your-git-script.sh "a b'c"
492 * Print the object name of the current commit:
495 $ git rev-parse --verify HEAD
498 * Print the commit object name from the revision in the $REV shell variable:
501 $ git rev-parse --verify --end-of-options $REV^{commit}
504 This will error out if $REV is empty or not a valid revision.
509 $ git rev-parse --default master --verify --end-of-options $REV
512 but if $REV is empty, the commit object name from master will be printed.
516 Part of the linkgit:git[1] suite