git/Documentation/gitk.txt, branch v2.4.7

Documentation: change -L: to -L:

2015-04-20T18:05:50Z

The old wording was somehow implying that and were not regular expressions. Also, the common case is to use a plain function name here so makes sense (the fact that it is a regular expression is documented in line-range-format.txt). Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

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

Documentation/gitk: document the location of the configulation file

2014-03-20T17:59:55Z

User config file location complies with the XDG base directory specification while supporting the traditional $HOME/.gitk as a fallback. Signed-off-by: Astril Hayato Signed-off-by: Junio C Hamano

Documentation/gitk: document -L option

2014-01-21T21:41:30Z

The -L option is the same as for git-log, so the entire block is just copied from git-log.txt. However, until the parser is fixed we add a caveat that gitk only understands the stuck form. Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

Documentation: revamp gitk(1)

2013-10-22T18:23:31Z

The gitk manpage suffers from a bit of neglect: there have been only minor changes, and no changes to the set of options documented, since a2df1fb (Documentation: New GUI configuration and command-line options., 2008-11-13). In the meantime, the set of rev-list options has been expanded several times by options that are useful in gitk, e.g., --ancestry-path and the optional globbing for --branches, --tags and --remotes. Restructure and expand the manpage. List more options that the author perceives as useful, while remaining somewhat terse. Ideally the user should not have to look up any of the references, but we dispense with precise explanations in some places and refer to git-log(1) instead. Note that the options that have an easy GUI equivalent (e.g., --word-diff, -S, --grep) are deliberately not listed even in the cases where they simply fill in the GUI fields. Signed-off-by: Thomas Rast 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.

Documentation: gitrevisions is in section 7

2010-10-14T02:10:55Z

Fix references to gitrevisions(1) in the manual pages and HTML documentation. In practice, this will not matter much unless someone tries to use a hard copy of the git reference manual. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Documentation: link to gitrevisions rather than git-rev-parse

2010-07-05T20:39:13Z

Currently, whenever we need documentation for revisions and ranges, we link to the git-rev-parse man page, i.e. a plumbing man page, which has this along with the documentation of all rev-parse modes. Link to the new gitrevisions man page instead in all cases except - when the actual git-rev-parse command is referred to or - in very technical context (git-send-pack). Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano