path: root/Documentation/git-rev-parse.txt
AgeCommit message (Collapse)Author
2020-12-13rev-parse: add option for absolute or relative path formattingbrian m. carlson
git rev-parse has several options which print various paths. Some of these paths are printed relative to the current working directory, and some are absolute. Normally, this is not a problem, but there are times when one wants paths entirely in one format or another. This can be done trivially if the paths are canonical, but canonicalizing paths is not possible on some shell scripting environments which lack realpath(1) and also in Go, which lacks functions that properly canonicalize paths on Windows. To help out the scripter, let's provide an option which turns most of the paths printed by git rev-parse to be either relative to the current working directory or absolute and canonical. Document which options are affected and which are not so that users are not confused. This approach is cleaner and tidier than providing duplicates of existing options which are either relative or absolute. Note that if the user needs both forms, it is possible to pass an additional option in the middle of the command line which changes the behavior of subsequent operations. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-11-10rev-parse: handle --end-of-optionsJeff King
We taught rev-list a new way to separate options from revisions in 19e8789b23 (revision: allow --end-of-options to end option parsing, 2019-08-06), but rev-parse uses its own parser. It should know about --end-of-options not only for consistency, but because it may be presented with similarly ambiguous cases. E.g., if a caller does: git rev-parse "$rev" -- "$path" to parse an untrusted input, then it will get confused if $rev contains an option-like string like "--local-env-vars". Or even "--not-real", which we'd keep as an option to pass along to rev-list. Or even more importantly: git rev-parse --verify "$rev" can be confused by options, even though its purpose is safely parsing untrusted input. On the plus side, it will always fail the --verify part, as it will not have parsed a revision, so the caller will generally "fail closed" rather than continue to use the untrusted string. But it will still trigger whatever option was in "$rev"; this should be mostly harmless, since rev-parse options are all read-only, but I didn't carefully audit all paths. This patch lets callers write: git rev-parse --end-of-options "$rev" -- "$path" and: git rev-parse --verify --end-of-options "$rev" which will both treat "$rev" always as a revision parameter. The latter is a bit clunky. It would be nicer if we had defined "--verify" to require that its next argument be the revision. But we have not historically done so, and: git rev-parse --verify -q "$rev" does currently work. I added a test here to confirm that we didn't break that. A few implementation notes: - We don't document --end-of-options explicitly in commands, but rather in gitcli(7). So I didn't give it its own section in git-rev-parse(1). But I did call it out specifically in the --verify section, and include it in the examples, which should show best practices. - We don't have to re-indent the main option-parsing block, because we can combine our "did we see end of options" check with "does it start with a dash". The exception is the pre-setup options, which need their own block. - We do however have to pull the "--" parsing out of the "does it start with dash" block, because we want to parse it even if we've seen --end-of-options. - We'll leave "--end-of-options" in the output. This is probably not technically necessary, as a careful caller will do: git rev-parse --end-of-options $revs -- $paths and anything in $revs will be resolved to an object id. However, it does help a slightly less careful caller like: git rev-parse --end-of-options $revs_or_paths where a path "--foo" will remain in the output as long as it also exists on disk. In that case, it's helpful to retain --end-of-options to get passed along to rev-list, s it would otherwise see just "--foo". Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2019-11-20rev-parse: make --show-toplevel without a worktree an errorJeff King
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 <>
2019-10-28rev-parse: add a --show-object-format optionbrian m. carlson
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 <>
2018-05-25Use proper syntax for replaceables in command docsRobert P. J. Day
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 <>
2017-10-28Merge branch 'sb/rev-parse-show-superproject-root'Junio C Hamano
Doc markup fix. * sb/rev-parse-show-superproject-root: docs: fix formatting of rev-parse's --show-superproject-working-tree
2017-10-27docs: fix formatting of rev-parse's --show-superproject-working-treeSebastian Schuberth
Signed-off-by: Sebastian Schuberth <> Signed-off-by: Junio C Hamano <>
2017-09-19rev-parse: rev-parse: add --is-shallow-repositoryØystein Walle
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 <>
2017-06-01doc: rewrite description for rev-parse --shortAndreas Heiduk
`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 <>
2017-03-08rev-parse: add --show-superproject-working-treeStefan Beller
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 <>
2017-02-04rev-parse: add '--absolute-git-dir' optionSZEDER Gábor
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=<path>' 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 <path>' 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 <path>' 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 <path> options on its own, and it can't just change directories as it pleases. Consequently, adding support for taking any '-C <path>' 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=<path>'. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2017-01-10rev-parse doc: pass "--" to rev-parse in the --prefix exampleRichard Hansen
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 <>
2015-07-15rev-parse --parseopt: allow [*=?!] in argument hintsIlya Bobyr
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 <value> 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 ./ --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 <>
2015-05-22Merge branch 'jk/asciidoc-markup-fix'Junio C Hamano
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'
2015-05-13doc: convert \--option to --optionJeff King
Older versions of AsciiDoc would convert the "--" in "--option" into an emdash. According to 565e135 (Documentation: quote double-dash for AsciiDoc, 2011-06-29), this is fixed in AsciiDoc 8.3.0. According to bf17126, we don't support anything older than 8.4.1 anyway, so we no longer need to worry about quoting. Even though this does not change the output at all, there are a few good reasons to drop the quoting: 1. It makes the source prettier to read. 2. We don't quote consistently, which may be confusing when reading the source. 3. Asciidoctor does not like the quoting, and renders a literal backslash. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-05-13doc: fix unquoted use of "{type}"Jeff King
Curly braces open an "attribute" in AsciiDoc; if there's no such attribute, strange things may happen. In this case, the unquoted "{type}" causes AsciiDoc to omit an entire line of text from the output. We can fix it by putting the whole phrase inside literal backticks (which also lets us get rid of ugly backslash escaping). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-12-01setup.c: support multi-checkout repo setupNguyễn Thái Ngọc Duy
The repo setup procedure is updated to detect $GIT_DIR/commondir and set $GIT_COMMON_DIR properly. The core.worktree is ignored when $GIT_COMMON_DIR is set. This is because the config file is shared in multi-checkout setup, but checkout directories _are_ different. Making core.worktree effective in all checkouts mean it's back to a single checkout. Helped-by: Johannes Sixt <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2014-12-01git_path(): be aware of file relocation in $GIT_DIRNguyễn Thái Ngọc Duy
We allow the user to relocate certain paths out of $GIT_DIR via environment variables, e.g. GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE and GIT_GRAFT_FILE. Callers are not supposed to use git_path() or git_pathdup() to get those paths. Instead they must use get_object_directory(), get_index_file() and get_graft_file() respectively. This is inconvenient and could be missed in review (for example, there's git_path("objects/info/alternates") somewhere in sha1_file.c). This patch makes git_path() and git_pathdup() understand those environment variables. So if you set GIT_OBJECT_DIRECTORY to /foo/bar, git_path("objects/abc") should return /foo/bar/abc. The same is done for the two remaining env variables. "git rev-parse --git-path" is the wrapper for script use. This patch kinda reverts a0279e1 (setup_git_env: use git_pathdup instead of xmalloc + sprintf - 2014-06-19) because using git_pathdup here would result in infinite recursion: setup_git_env() -> git_pathdup("objects") -> .. -> adjust_git_path() -> get_object_directory() -> oops, git_object_directory is NOT set yet -> setup_git_env() I wanted to make git_pathdup_literal() that skips adjust_git_path(). But that won't work because later on when $GIT_COMMON_DIR is introduced, git_pathdup_literal("objects") needs adjust_git_path() to replace $GIT_DIR with $GIT_COMMON_DIR. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2014-11-04Documentation: typofixesThomas Ackermann
In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann <> Signed-off-by: Junio C Hamano <>
2014-09-15Documentation: a note about stdout for git rev-parse --verify --quietDavid Aguilar
Signed-off-by: David Aguilar <> Signed-off-by: Junio C Hamano <>
2014-07-22Sync with maintJunio C Hamano
* maint: Documentation: fix missing text for rev-parse --verify
2014-07-22Merge branch 'maint-1.9' into maintJunio C Hamano
* maint-1.9: Documentation: fix missing text for rev-parse --verify
2014-07-22Merge branch 'maint-1.8.5' into maint-1.9Junio C Hamano
* maint-1.8.5: Documentation: fix missing text for rev-parse --verify
2014-07-22Documentation: fix missing text for rev-parse --verifybrian m. carlson
The caret (^) is used as a markup symbol in AsciiDoc. Due to the inability of AsciiDoc to parse a line containing an unmatched caret, it omitted the line from the output, resulting in the man page missing the end of a sentence. Escape this caret so that the man page ends up with the complete text. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2014-06-13rev-parse: add --shared-index-path to get shared index pathNguyễn Thái Ngọc Duy
Normally scripts do not have to be aware about split indexes because all shared indexes are in $GIT_DIR. A simple "mv $tmp_index $GIT_DIR/somewhere" is enough. Scripts that generate temporary indexes and move them across repos must be aware about split index and copy the shared file as well. This option enables that. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2014-04-08Merge branch 'ib/rev-parse-parseopt-argh'Junio C Hamano
Finishing touch to a new topic scheduled for 2.0. * ib/rev-parse-parseopt-argh: rev-parse: fix typo in example on manpage
2014-04-01rev-parse: fix typo in example on manpageRené Scharfe
Signed-off-by: Junio C Hamano <>
2014-03-24parse-options: multi-word argh should use dash to separate wordsJunio C Hamano
"When you need to use space, use dash" is a strange way to say that you must not use a space. Because it is more common for the command line descriptions to use dashed-multi-words, you do not even want to use spaces in these places. Rephrase the documentation to avoid this strangeness. Fix a few existing multi-word argument help strings, i.e. - GPG key-ids given to -S/--gpg-sign are "key-id"; - Refs used for storing notes are "notes-ref"; and - Expiry timestamps given to --expire are "expiry-date". and update the corresponding documentation pages. Signed-off-by: Junio C Hamano <>
2014-03-24rev-parse --parseopt: option argument name hintsIlya Bobyr
Built-in commands can specify names for option arguments when usage text is generated for a command. sh based commands should be able to do the same. Option argument name hint is any text that comes after [*=?!] after the argument name up to the first whitespace. Signed-off-by: Ilya Bobyr <> Signed-off-by: Junio C Hamano <>
2013-12-05Merge branch 'jc/ref-excludes'Junio C Hamano
People often wished a way to tell "git log --branches" (and "git log --remotes --not --branches") to exclude some local branches from the expansion of "--branches" (similarly for "--tags", "--all" and "--glob=<pattern>"). Now they have one. * jc/ref-excludes: rev-parse: introduce --exclude=<glob> to tame wildcards rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API rev-list --exclude: tests document --exclude option revision: introduce --exclude=<glob> to tame wildcards
2013-11-01rev-parse: introduce --exclude=<glob> to tame wildcardsJunio C Hamano
Teach "rev-parse" the same "I'm going to glob, but omit the ones that match these patterns" feature as "rev-list". Signed-off-by: Junio C Hamano <>
2013-10-31rev-parse --parseopt: add the --stuck-long modeNicolas Vigier
Add the --stuck-long option to output the options in their long form if available, and with their arguments stuck. Contrary to the default form (non stuck arguments and short options), this can be parsed unambiguously when using options with optional arguments : - in the non stuck form, when an option is taking an optional argument you cannot know if the next argument is its optional argument, or the next option. - the long options form allows to differentiate between an empty argument '--option=' and an unset argument '--option', which is not possible with short options. Signed-off-by: Nicolas Vigier <> Signed-off-by: Junio C Hamano <>
2013-08-30Merge branch 'rj/doc-rev-parse'Junio C Hamano
* rj/doc-rev-parse: rev-parse(1): logically group options rev-parse: remove restrictions on some options
2013-07-22typofix: documentationOndřej Bílka
Signed-off-by: Ondřej Bílka <> Signed-off-by: Junio C Hamano <>
2013-07-22rev-parse(1): logically group optionsJohn Keeping
The options section of the git-rev-parse manual page has grown organically so that there now does not seem to be much logic behind the ordering of the options. It also does not make it clear that certain options must appear first on the command line. Address this by reorganising the options into groups with subheadings. The text of option descriptions does not change. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-06-17rev-parse: add --prefix optionJohn Keeping
This makes 'git rev-parse' behave as if it were invoked from the specified subdirectory of a repository, with the difference that any file paths which it prints are prefixed with the full path from the top of the working tree. This is useful for shell scripts where we may want to cd to the top of the working tree but need to handle relative paths given by the user on the command line. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-04-22Merge branch 'ta/glossary'Junio C Hamano
* ta/glossary: glossary: improve definitions of refspec and pathspec The name of the hash function is "SHA-1", not "SHA1" glossary: improve description of SHA-1 related topics glossary: remove outdated/misleading/irrelevant entries
2013-04-15The name of the hash function is "SHA-1", not "SHA1"Thomas Ackermann
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann <> Signed-off-by: Junio C Hamano <>
2013-04-05Merge branch 'mh/rev-parse-verify-doc'Junio C Hamano
"rev-parse --verify" was documented in a misleading way. * mh/rev-parse-verify-doc: rev-parse: clarify documentation for the --verify option
2013-04-02rev-parse: clarify documentation for the --verify optionMichael Haggerty
The old version could be read to mean that the argument has to refer to a valid object, but that is incorrect: * the object is not necessarily read (e.g., to check for corruption) * if the argument is a 40-digit string of hex digits, then it is accepted whether or not is is the name of an existing object. So reword the explanation to be less ambiguous. Also fix the examples involving --verify: to be sure that the argument refers to a commit (rather than some other kind of object), the argument has to be suffixed with "^{commit}". This trick is not possible in the example involving --default, so don't imply that it is exactly the same as the previous example. Signed-off-by: Michael Haggerty <> Signed-off-by: Junio C Hamano <>
2013-02-01Documentation: do not use undefined terms git-dir and git-fileThomas Ackermann
We will add gitfile to the glossary in a separate commit. Signed-off-by: Thomas Ackermann <> Signed-off-by: Junio C Hamano <>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Thomas Ackermann
Signed-off-by: Thomas Ackermann <> Signed-off-by: Junio C Hamano <>
2012-07-22Merge branch 'jc/sha1-name-more'Junio C Hamano
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...
2012-07-09rev-parse --disambiguate=<prefix>Junio C Hamano
The new option allows you to feed an ambiguous prefix and enumerate all the objects that share it as a prefix of their object names. Signed-off-by: Junio C Hamano <>
2012-05-23Merge branch 'js/rev-parse-doc-fix'Junio C Hamano
By Jon Seymour * js/rev-parse-doc-fix: rev-parse doc: --git-dir does not always show a relative path
2012-05-18rev-parse doc: --git-dir does not always show a relative pathJon Seymour
The description was misleading because it lead the reader to believe that --git-dir would always show a relative path when, in fact, the actual behaviour does not guarantee this. Rather, it was intended that the advice be given that if a relative path is shown, then the path is relative to the current working directory and not some other directory (for example, the root of the working tree). Signed-off-by: Jon Seymour <> Acked-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2012-04-26docs: stop using asciidoc no-inline-literalJeff King
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <>` used to erroneously auto-generate a mailto footnote for - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-16rev-parse: add option --resolve-git-dir <path>Fredrik Gustafsson
Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <> Mentored-by: Jens Lehmann <> Mentored-by: Heiko Voigt <> Signed-off-by: Junio C Hamano <>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsMartin von Zweigbergk
The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <> Signed-off-by: Junio C Hamano <>
2011-03-11doc: drop author/documentation sections from most pagesJeff King
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.