git/Documentation/git-rev-parse.txt, branch v2.24.2

Use proper syntax for replaceables in command docs

2018-05-25T08:16:47Z

The standard for command documentation synopses appears to be: [...] means optional <...> means replaceable [<...>] means both optional and replaceable So fix a number of doc pages that use incorrect variations of the above. Signed-off-by: Robert P. J. Day Signed-off-by: Junio C Hamano

Merge branch 'sb/rev-parse-show-superproject-root'

2017-10-28T01:18:40Z

Doc markup fix. * sb/rev-parse-show-superproject-root: docs: fix formatting of rev-parse's --show-superproject-working-tree

docs: fix formatting of rev-parse's --show-superproject-working-tree

2017-10-27T01:31:46Z

Signed-off-by: Sebastian Schuberth Signed-off-by: Junio C Hamano

rev-parse: rev-parse: add --is-shallow-repository

2017-09-19T03:16:28Z

Running `git fetch --unshallow` on a repo that is not in fact shallow produces a fatal error message. Add a helper to rev-parse that scripters can use to determine whether a repo is shallow or not. Signed-off-by: Øystein Walle Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

doc: rewrite description for rev-parse --short

2017-06-01T01:37:42Z

`git rev-parse --short` is not a generic modifier but just a variant of `--verify` and considers the given length only as a suggestion to ensure uniqueness. Signed-off-by: Andreas Heiduk Signed-off-by: Junio C Hamano

rev-parse: add --show-superproject-working-tree

2017-03-08T23:52:03Z

In some situations it is useful to know if the given repository is a submodule of another repository. Add the flag --show-superproject-working-tree to git-rev-parse to make it easy to find out if there is a superproject. When no superproject exists, the output will be empty. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

rev-parse: add '--absolute-git-dir' option

2017-02-04T06:18:41Z

The output of 'git rev-parse --git-dir' can be either a relative or an absolute path, depending on whether the current working directory is at the top of the worktree or the .git directory or not, or how the path to the repository is specified via the '--git-dir=' option or the $GIT_DIR environment variable. And if that output is a relative path, then it is relative to the directory where any 'git -C ' options might have led us. This doesn't matter at all for regular scripts, because the git wrapper automatically takes care of changing directories according to the '-C ' options, and the scripts can then simply follow any path returned by 'git rev-parse --git-dir', even if it's a relative path. Our Bash completion script, however, is unique in that it must run directly in the user's interactive shell environment. This means that it's not executed through the git wrapper and would have to take care of any '-C options on its own, and it can't just change directories as it pleases. Consequently, adding support for taking any '-C ' options on the command line into account during completion turned out to be considerably more difficult, error prone and required more subshells and git processes when it had to cope with a relative path to the .git directory. Help this rather special use case and teach 'git rev-parse' a new '--absolute-git-dir' option which always outputs a canonicalized absolute path to the .git directory, regardless of whether the path is discovered automatically or is specified via $GIT_DIR or 'git --git-dir='. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

rev-parse doc: pass "--" to rev-parse in the --prefix example

2017-01-10T21:22:19Z

The "--" argument avoids "ambiguous argument: unknown revision or path not in the working tree" errors when a pathname argument refers to a non-existent file. The "--" passed explicitly to set was removed because rev-parse outputs the "--" argument that it is given. Signed-off-by: Richard Hansen Signed-off-by: Junio C Hamano

rev-parse --parseopt: allow [*=?!] in argument hints

2015-07-15T17:30:54Z

A line in the input to "rev-parse --parseopt" describes an option by listing a short and/or long name, optional flags [*=?!], argument hint, and then whitespace and help string. We did not allow any of the [*=?!] characters in the argument hints. The following input pair=key=value equals sign in the hint used to generate a help line like this: --pair=key equals sign in the hint and used to expect "pair=key" as the argument name. That is not very helpful as we generally do not want any of the [*=?!] characters in the argument names. But we do want to use at least the equals sign in the argument hints. Update the parser to make long argument names stop at the first [*=?!] character. Add test case with equals sign in the argument hint and update the test to perform all the operations in test_expect_success matching the t/README requirements and allowing commands like ./t1502-rev-parse-parseopt.sh --run=1-2 to stop at the test case 2 without any further modification of the test state area. Signed-off-by: Ilya Bobyr Signed-off-by: Junio C Hamano

Merge branch 'jk/asciidoc-markup-fix'

2015-05-22T19:41:50Z

Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote'