git/Documentation/git-help.txt, branch v2.3.7

Documentation: use "command-line" when used as a compound adjective, and fix other minor grammatical issues

2014-05-21T20:57:10Z

Signed-off-by: Jason St. John Signed-off-by: Junio C Hamano

doc: include --guide option description for "git help"

2013-04-03T14:43:29Z

Note that the ability to display an individual guide was always possible. Include this in the update. Also tell readers how git(1) can be accessed, especially for Git for Windows users who do not have the 'man' command. Likewise include a commentary on how to access this page (Catch 22). Signed-off-by: Philip Oakley Signed-off-by: Junio C Hamano

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33Z

Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano

Documentation: use [verse] for SYNOPSIS sections

2011-07-06T21:26:26Z

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

doc: drop author/documentation sections from most pages

2011-03-11T15:59:16Z

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.

Work around em-dash handling in newer AsciiDoc

2010-08-24T16:48:20Z

Older versions of AsciiDoc used to literally pass double dashes when we used them in our linkgit macros and manpage titles, but newer ones (the issue was first reported with AsciiDoc 8.5.2) turn them into em dashes. Define litdd (literal double-dash) custom attribute in asciidoc.conf to work this around. While we are at it, fix a few double-dashes (e.g. the description of "project--devo--version" convention used by tla, among other things) that used to be incorrectly written as em dashes in the body text to also use this attribute. Signed-off-by: Junio C Hamano

Documentation: spell 'git cmd' without dash throughout

2010-01-10T12:01:28Z

The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.

builtin-help: fallback to GIT_MAN_VIEWER before man

2008-08-30T04:46:33Z

In some situations it is useful to be able to switch viewers via the environment, e.g. in Emacs shell buffers. So check the GIT_MAN_VIEWER environment variable and try it before falling back to "man". Signed-off-by: Romain Francoise Signed-off-by: Junio C Hamano

manpages: use teletype font for sample command lines

2008-07-05T18:24:40Z

I think that some of these uses of italics were meant to be rendered in quotation marks, anyway. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

manpages: italicize git command names (which were in teletype font)

2008-07-05T18:24:40Z

The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano