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

rev-parse: make --show-toplevel without a worktree an error

2019-11-20T01:19:58Z

Ever since it was introduced in 7cceca5ccc (Add 'git rev-parse --show-toplevel' option., 2010-01-12), the --show-toplevel option has treated a missing working tree as a quiet success: it neither prints a toplevel path, but nor does it report any kind of error. While a caller could distinguish this case by looking for an empty response, the behavior is rather confusing. We're better off complaining that there is no working tree, as other internal commands would do in similar cases (e.g., "git status" or any builtin with NEED_WORK_TREE set would just die()). So let's do the same here. While we're at it, let's clarify the documentation and add some tests, both for the new behavior and for the more mundane case (which was not covered). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

rev-parse: add a --show-object-format option

2019-10-28T02:34:57Z

Add an option to print the object format used for input, output, or storage. This allows shell scripts to discover the hash algorithm in use. Since the transition plan allows for multiple input algorithms, document that we may provide multiple results for input, and the format that the results may take. While we don't support this now, documenting it early means that script authors can future-proof their scripts for when we do. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

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