aboutsummaryrefslogtreecommitdiff
path: root/Documentation/git-log.txt
Commit message (Collapse)AuthorAge
* log: add option to choose which refs to decorateRafael Ascensão2017-11-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When `log --decorate` is used, git will decorate commits with all available refs. While in most cases this may give the desired effect, under some conditions it can lead to excessively verbose output. Introduce two command line options, `--decorate-refs=<pattern>` and `--decorate-refs-exclude=<pattern>` to allow the user to select which refs are used in decoration. When "--decorate-refs=<pattern>" is given, only the refs that match the pattern are used in decoration. The refs that match the pattern when "--decorate-refs-exclude=<pattern>" is given, are never used in decoration. These options follow the same convention for mixing negative and positive patterns across the system, assuming that the inclusive default is to match all refs available. (1) if there is no positive pattern given, pretend as if an inclusive default positive pattern was given; (2) for each candidate, reject it if it matches no positive pattern, or if it matches any one of the negative patterns. The rules for what is considered a match are slightly different from the rules used elsewhere. Commands like `log --glob` assume a trailing '/*' when glob chars are not present in the pattern. This makes it difficult to specify a single ref. On the other hand, commands like `describe --match --all` allow specifying exact refs, but do not have the convenience of allowing "shorthand refs" like 'refs/heads' or 'heads' to refer to 'refs/heads/*'. The commands introduced in this patch consider a match if: (a) the pattern contains globs chars, and regular pattern matching returns a match. (b) the pattern does not contain glob chars, and ref '<pattern>' exists, or if ref exists under '<pattern>/' This allows both behaviours (allowing single refs and shorthand refs) yet remaining compatible with existent commands. Helped-by: Kevin Daudt <me@ikke.info> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mj/log-show-signature-conf'Junio C Hamano2016-07-11
|\ | | | | | | | | | | | | | | | | | | "git log" learns log.showSignature configuration variable, and a command line option "--no-show-signature" to countermand it. * mj/log-show-signature-conf: log: add log.showSignature configuration variable log: add "--no-show-signature" command line option t4202: refactor test
| * log: add log.showSignature configuration variableMehul Jain2016-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users may want to always use "--show-signature" while using git-log and related commands. When log.showSignature is set to true, git-log and related commands will behave as if "--show-signature" was given to them. Note that this config variable is meant to affect git-log, git-show, git-whatchanged and git-reflog. Other commands like git-format-patch, git-rev-list are not to be affected by this config variable. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'tr/doc-tt'Junio C Hamano2016-06-27
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | The documentation set has been updated so that literal commands, configuration variables and environment variables are consistently typeset in fixed-width font and bold in manpages. * tr/doc-tt: doc: change configuration variables format doc: more consistency in environment variables format doc: change environment variables format doc: clearer rule about formatting literals
| * doc: change environment variables formatTom Russello2016-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change GIT_* variables that where in italic style to monospaced font according to the guideline. It was obtained with perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rj/log-decorate-auto'Junio C Hamano2016-05-29
|\ \ | |/ |/| | | | | | | | | | | We forgot to add "git log --decorate=auto" to documentation when we added the feature back in v2.1.0 timeframe. * rj/log-decorate-auto: log: document the --decorate=auto option
| * log: document the --decorate=auto optionRamsay Jones2016-05-27
| | | | | | | | | | Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log: Update log.follow doc and add to config.txtEric N. Vander Weele2015-10-07
| | | | | | | | | | | | | | | | | | | | | | | | Documentation/config.txt does not include the documentation for log.follow that is in Documentation/git-log.txt. This commit adds the log.follow documentation to config.txt and also updates the wording to be consistent with the format that is followed by other boolean configuration variables. Signed-off-by: Eric N. Vander Weele <ericvw@gmail.com> Acked-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log: add "log.follow" configuration variableDavid Turner2015-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | People who work on projects with mostly linear history with frequent whole file renames may want to always use "git log --follow" when inspecting the life of the content that live in a single path. Teach the command to behave as if "--follow" was given from the command line when log.follow configuration variable is set *and* there is one (and only one) path on the command line. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'mm/usage-log-l-can-take-regex'Junio C Hamano2015-05-05
|\ \ | | | | | | | | | | | | | | | | | | | | | Documentation fix. * mm/usage-log-l-can-take-regex: log -L: improve error message on malformed argument Documentation: change -L:<regex> to -L:<funcname>
| * | Documentation: change -L:<regex> to -L:<funcname>Matthieu Moy2015-04-20
| |/ | | | | | | | | | | | | | | | | | | The old wording was somehow implying that <start> and <end> were not regular expressions. Also, the common case is to use a plain function name here so <funcname> makes sense (the fact that it is a regular expression is documented in line-range-format.txt). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | *config.txt: stick to camelCase naming conventionNguyễn Thái Ngọc Duy2015-03-13
|/ | | | | | | | | | | | | | | | | | | | This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jj/log-doc'Junio C Hamano2013-12-03
|\ | | | | | | | | | | | | | | Mark-up fixes. * jj/log-doc: Documentation/git-log.txt: mark-up fix and minor rephasing Documentation/git-log: update "--log-size" description
| * Documentation/git-log.txt: mark-up fix and minor rephasingJason St. John2013-11-13
| | | | | | | | | | | | | | | | | | | | - typeset options, commands, and paths in monospace; - typeset references to sections with emphasis; - replace some double quotes with proper AsciiDoc quotes (e.g. ``foo''); - use title case when referring to section headings. Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Documentation/git-log: update "--log-size" descriptionJason St. John2013-11-13
| | | | | | | | | | | | | | | | | | | | | | "--log-size" was added in commit 9fa3465, and the commit message contained a satisfactory explanation; however, the man page entry for it did not describe the actual output format, what the output meant and what the option was meant to be used for. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | line-range-format.txt: clarify -L:regex usage formEric Sunshine2013-08-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | blame/log documentation describes -L option as: -L<start>,<end> -L:<regex> <start> and <end> can take one of these forms: * number * /regex/ * +offset or -offset * :regex which is incorrect and confusing since :regex is not one of the valid forms of <start> or <end>; in fact, it must be -L's lone argument. Clarify by discussing :<regex> at the same indentation level as "<start> and <end>...": -L<start>,<end> -L:<regex> <start> and <end> can take one of these forms: * number * /regex/ * +offset or -offset If :<regex> is given in place of <start> and <end> ... Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-log.txt: place each -L option variation on its own lineEric Sunshine2013-08-06
|/ | | | | | | | | | | | | Standard practice in Git documentation is for each variation of an option (such as: -p / --porcelain) to be placed on its own line in the OPTIONS table. The -L option does not follow suit. It cuddles "-L <start>,<end>:<file>" and "-L :<regex>:<file>", separated by a comma. This is inconsistent and potentially confusing since the comma separating them is typeset the same as the comma in "<start>,<end>". Fix this by placing each variation on its own line. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mm/diff-no-patch-synonym-to-s'Junio C Hamano2013-07-22
|\ | | | | | | | | | | | | | | | | | | | | | | "git show -s" was less discoverable than it should be. * mm/diff-no-patch-synonym-to-s: Documentation/git-log.txt: capitalize section names Documentation: move description of -s, --no-patch to diff-options.txt Documentation/git-show.txt: include common diff options, like git-log.txt diff: allow --patch & cie to override -s/--no-patch diff: allow --no-patch as synonym for -s t4000-diff-format.sh: modernize style
| * Documentation/git-log.txt: capitalize section namesMatthieu Moy2013-07-17
| | | | | | | | | | | | | | | | | | This is the convention in most other files and even at the beginning of git-log.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-log.txt: fix typesetting of example "git-log -L" invocationEric Sunshine2013-07-17
| | | | | | | | | | | | | | | | All surrounding examples are typeset as monospaced text. Follow suit. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ph/builtin-srcs-are-in-subdir-these-days'Junio C Hamano2013-06-26
|\ \ | | | | | | | | | | | | * ph/builtin-srcs-are-in-subdir-these-days: fix "builtin-*" references to be "builtin/*"
| * | fix "builtin-*" references to be "builtin/*"Phil Hord2013-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Documentation and some comments still refer to files in builtin/ as 'builtin-*.[cho]'. Update these to show the correct location. Signed-off-by: Phil Hord <hordp@cisco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Assisted-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'tr/line-log'Junio C Hamano2013-06-02
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * tr/line-log: git-log(1): remove --full-line-diff description line-log: fix documentation formatting log -L: improve comments in process_all_files() log -L: store the path instead of a diff_filespec log -L: test merge of parallel modify/rename t4211: pass -M to 'git log -M -L...' test log -L: fix overlapping input ranges log -L: check range set invariants when we look it up Speed up log -L... -M log -L: :pattern:file syntax to find by funcname Implement line-history search (git log -L) Export rewrite_parents() for 'log -L' Refactor parse_loc
| * | git-log(1): remove --full-line-diff descriptionThomas Rast2013-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | This option is a remnant of an earlier log -L version, and not currently implemented. Remove it until (if at all) it is implemented again. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | line-log: fix documentation formattingJunio C Hamano2013-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The second paragraph of the added description for the -L option "<start> and <end> can take one of these forms:", and the list of forms that follow the headline, were indented one level too short, due to the missing "+" to signal that the next paragraph continues the previous one. Also "You can specify this option more than once" is about the -L option, not about its various forms of starting and ending points. Move it to the end of the main text. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | log -L: :pattern:file syntax to find by funcnameThomas Rast2013-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new syntax finds a funcname matching /pattern/, and then takes from there up to (but not including) the next funcname. So you can say git log -L:main:main.c and it will dig up the main() function and show its line-log, provided there are no other funcnames matching 'main'. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Implement line-history search (git log -L)Thomas Rast2013-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a rewrite of much of Bo's work, mainly in an effort to split it into smaller, easier to understand routines. The algorithm is built around the struct range_set, which encodes a series of line ranges as intervals [a,b). This is used in two contexts: * A set of lines we are tracking (which will change as we dig through history). * To encode diffs, as pairs of ranges. The main routine is range_set_map_across_diff(). It processes the diff between a commit C and some parent P. It determines which diff hunks are relevant to the ranges tracked in C, and computes the new ranges for P. The algorithm is then simply to process history in topological order from newest to oldest, computing ranges and (partial) diffs. At branch points, we need to merge the ranges we are watching. We will find that many commits do not affect the chosen ranges, and mark them TREESAME (in addition to those already filtered by pathspec limiting). Another pass of history simplification then gets rid of such commits. This is wired as an extra filtering pass in the log machinery. This currently only reduces code duplication, but should allow for other simplifications and options to be used. Finally, we hook a diff printer into the output chain. Ideally we would wire directly into the diff logic, to optionally use features like word diff. However, that will require some major reworking of the diff chain, so we completely replace the output with our own diff for now. As this was a GSoC project, and has quite some history by now, many people have helped. In no particular order, thanks go to Jakub Narebski <jnareb@gmail.com> Jens Lehmann <Jens.Lehmann@web.de> Jonathan Nieder <jrnieder@gmail.com> Junio C Hamano <gitster@pobox.com> Ramsay Jones <ramsay@ramsay1.demon.co.uk> Will Palmer <wmpalmer@gmail.com> Apologies to everyone I forgot. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | git-log.txt: rewrite note on why "--" may be requiredRamkumar Ramachandra2013-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In its current form, the note talks about separating options from "branch names" and "refnames" in the same sentence. This is entirely inaccurate, as <revision range> need not be a set of branch names or ref names. Rewrite it to use the word "revision range", to be consistent with the SYNOPSIS. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | git-log.txt: generalize <since>..<until>Ramkumar Ramachandra2013-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '<since>..<until>' is misleading, as there are many other forms that 'git log' can accept as an argument. Replace it with <revision range>, referring to the section "Specifying Ranges" in revisions.txt, and rewrite the section appropriately. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | git-log.txt: order OPTIONS properly; move <since>..<until>Ramkumar Ramachandra2013-04-21
|/ / | | | | | | | | | | | | | | | | The OPTIONS section lists <since>..<until> as the first item, but this is inconsistent with the ordering in SYNOPSIS. Move it down until it appears just before [[--] <path>...]. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation: the name of the system is 'Git', not 'git'Thomas Ackermann2013-02-01
| | | | | | | | | | Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ap/log-mailmap'Junio C Hamano2013-01-20
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach commands in the "log" family to optionally pay attention to the mailmap. * ap/log-mailmap: log --use-mailmap: optimize for cases without --author/--committer search log: add log.mailmap configuration option log: grep author/committer using mailmap test: add test for --use-mailmap option log: add --use-mailmap option pretty: use mailmap to display username and email mailmap: add mailmap structure to rev_info and pp mailmap: simplify map_user() interface mailmap: remove email copy and length limitation Use split_ident_line to parse author and committer string-list: allow case-insensitive string list
| * | log: add --use-mailmap optionAntoine Pelisse2013-01-10
| |/ | | | | | | | | | | | | | | | | Add the --use-mailmap option to log commands. It allows to display names from mailmap file when displaying logs, whatever the format used. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailmap: fix some documentation loose-ends for mailmap.blobJeff King2012-12-13
|/ | | | | | | | Anywhere we mention mailmap.file, it is probably worth mentioning mailmap.blob, as well. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc: move rev-list option -<n> from git-log.txt to rev-list-options.txtNguyễn Thái Ngọc Duy2012-09-06
| | | | | | | | | rev-list-options.txt is included in git-rev-list.txt. This makes sure rev-list man page also shows that, and at one place, together with equivalent options -n and --max-count. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* docs: stop using asciidoc no-inline-literalJeff King2012-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2011-08-30
|\ | | | | | | | | * maint: Documentation: clarify effects of -- <path> arguments
| * Documentation: clarify effects of -- <path> argumentsThomas Rast2011-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | 'git log -- <path>' does not "show commits that affect the specified paths" in a literal sense unless --full-history is given (for example, a file that only existed on a side branch will turn up no commits at all!). Reword it to specify the actual intent of the filtering, and point to the "History Simplification" section. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | docs: put listed example commands in backticksJeff King2011-08-04
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Many examples of git command invocation are given in asciidoc listing blocks, which makes them monospaced and avoids further interpretation of special characters. Some manpages make a list of examples, like: git foo:: Run git foo. git foo -q:: Use the "-q" option. to quickly show many variants. However, they can sometimes be hard to read, because they are shown in a proportional-width font (so, for example, seeing the difference between "-- foo" and "--foo" can be difficult). This patch puts all such examples into backticks, which gives the equivalent formatting to a listing block (i.e., monospaced and without character interpretation). As a bonus, this also fixes an example in the git-push manpage, in which "git push origin :::" was accidentally considered a newly-indented list, and not a list item with "git push origin :" in it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: use [verse] for SYNOPSIS sectionsMartin von Zweigbergk2011-07-06
| | | | | | | | | | | | | | | | | | | | | | 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 <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* log/pretty-options: Document --[no-]notes and deprecate old notes optionsJohan Herland2011-03-30
| | | | | | | | | | Document the behavior or the new --notes, --notes=<ref> and --no-notes options, and list --show-notes[=<ref>] and --[no-]standard-notes options as deprecated. Signed-off-by: Johan Herland <johan@herland.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mg/rev-list-n-reverse-doc'Junio C Hamano2011-03-19
|\ | | | | | | | | | | * mg/rev-list-n-reverse-doc: git-log.txt,rev-list-options.txt: put option blocks in proper order git-log.txt,rev-list-options.txt: -n/--max-count is commit limiting
| * git-log.txt,rev-list-options.txt: put option blocks in proper orderMichael J Gruber2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | Match the order of the description to the one in which they get applied: commit limiting commit ordering commit formatting diff options Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-log.txt,rev-list-options.txt: -n/--max-count is commit limitingMichael J Gruber2011-03-08
| | | | | | | | | | | | | | | | They are applied after commit ordering and formatting options, in particular --reverse. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | doc: drop author/documentation sections from most pagesJeff King2011-03-11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Replace "remote tracking" with "remote-tracking"Matthieu Moy2010-11-03
| | | | | | | | | | | | | | | | | | "remote-tracking" branch makes it explicit that the branch is "tracking a remote", as opposed to "remote, and tracking something". See discussion in e.g. http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com for more details. This patch is a straightforward application of perl -pi -e 's/remote tracking branch/remote-tracking branch/' except in the RelNotes directory. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: gitrevisions is in section 7Jonathan Nieder2010-10-13
| | | | | | | | | | | 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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/git-log: Clarify --full-diffMichael J Gruber2010-08-09
| | | | | | | | | | The current description gives the impression that "--full-diff" affects "log -p" only. Make it clearer that it affects all diff-based output types. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'eb/doc-log-manpage'Junio C Hamano2010-07-15
|\ | | | | | | | | * eb/doc-log-manpage: Reorganize `git-log' man page to clarify common diff options.
| * Reorganize `git-log' man page to clarify common diff options.Eli Barzilay2010-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will reduce considerably the common confusion where people miss the `--follow' option, and wonder why `-M'/`-C' is not working. * Move the diff options include to after the log-specific flags, and add a "Common diff options" subtitle before them. (These options apply only when patches are shown, which is not a common use case among newbies, so having them first is confusing.) * Move the `--follow' description to the top of the listed options. The options before that seem less important: `--full-diff' applies only when patches are shown, `--source' and `--decorate' are less useful with many common commit specifications. * Clarify that `--follow' works only for a single path argument. Signed-off-by: Eli Barzilay <eli@barzilay.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-06-01 20:39:52 +0000