summaryrefslogtreecommitdiff
path: root/Documentation/git-log.txt
AgeCommit message (Collapse)AuthorFilesLines
2020-08-17Merge branch 'so/log-diff-merges-opt'Libravatar Junio C Hamano1-1/+5
Earlier, to countermand the implicit "-m" option when the "--first-parent" option is used with "git log", we added the "--[no-]diff-merges" option in the jk/log-fp-implies-m topic. To leave the door open to allow the "--diff-merges" option to take values that instructs how patches for merge commits should be computed (e.g. "cc"? "-p against first parent?"), redefine "--diff-merges" to take non-optional value, and implement "off" that means the same thing as "--no-diff-merges". * so/log-diff-merges-opt: t/t4013: add test for --diff-merges=off doc/git-log: describe --diff-merges=off revision: change "--diff-merges" option to require parameter
2020-08-17Merge branch 'jk/log-fp-implies-m'Libravatar Junio C Hamano1-2/+41
"git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. * jk/log-fp-implies-m: doc/git-log: clarify handling of merge commit diffs doc/git-log: move "-t" into diff-options list doc/git-log: drop "-r" diff option doc/git-log: move "Diff Formatting" from rev-list-options log: enable "-m" automatically with "--first-parent" revision: add "--no-diff-merges" option to counteract "-m" log: drop "--cc implies -m" logic
2020-08-11doc/git-log: describe --diff-merges=offLibravatar Sergey Organov1-1/+5
Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: clarify handling of merge commit diffsLibravatar Jeff King1-0/+7
It can be surprising that git-log doesn't show any diff for merge commits by default. Arguably "--cc" would be a reasonable default, but it's very expensive (which is why we turn it on for "git show" but not for "git log"). Let's at least document the current behavior, including the recent "--first-parent implies -m" case Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: move "-t" into diff-options listLibravatar Jeff King1-3/+0
The "-t" option is infrequently used; it doesn't deserve a spot near the top of the options list. Let's push it down into the diff-options include, near the definition of --raw. We'll protect it with a git-log ifdef, since it doesn't make any sense for non-tree diff commands. Note that this means it also shows up in git-show, but that's a good thing; it applies equally well there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: drop "-r" diff optionLibravatar Jeff King1-4/+1
This has been the default since 170c04383b (Porcelain level "log" family should recurse when diffing., 2007-08-27). There's not even a way to turn it off, so you'd never even want "-r" to override that. It's not the default for plumbing like diff-tree, of course, but the option is documented separately there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29doc/git-log: move "Diff Formatting" from rev-list-optionsLibravatar Jeff King1-2/+40
Our rev-list-options.txt include has a "Diff Formatting" section, but it is ifndef'd out for all manpages except git-log. And a few bits of the text are rather out of date. We say "some of these options are specific to git-rev-list". That's obviously silly since we (even before this patch) show the content only for git-log. But moreover, it's not true; each of the listed options is meaningful for other diff commands. We also say "...however other diff options may be given. See git-diff-files for more options." But there's no need to do so; git-log already has a "Common Diff Options" section which includes diff-options.txt. So let's move these options over to git-log and put them with the other diff options, giving a single "diff" section for the git-log documentation. We'll call it "Diff Formatting" but use the all-caps top-level header to match its sibling sections. And we'll rewrite the section intro to remove the useless bits and give a more generic overview of the section which can be later extended. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08git-log.txt: include rev-list-description.txtLibravatar Philippe Blain1-0/+3
The `git log` synopsis mentions `<revision range>`, and the description of this option links to gitrevisions(7), but a nice explanation of how a revision range can be constructed from individual commits, optionnally prefixed with `^`, also exists in `rev-list-description.txt`. Include this description in the man page for `git log`. Add Asciidoc 'ifdef's to `rev-list-description.txt` so that either `git rev-list` or `git log` appears in the respective man pages. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08git-log.txt: add links to 'rev-list' and 'diff' docsLibravatar Philippe Blain1-2/+2
Add links to the documentation for `git rev-list` and `git diff` instead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link to `git diff` as this is the porcelain command, and the rest of the family (`diff-index`, `diff-tree` and `diff-files`) are mentioned in the "Raw output format" section of the `git diff` documentation. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28Merge branch 'ds/log-exclude-decoration-config'Libravatar Junio C Hamano1-1/+4
The "--decorate-refs" and "--decorate-refs-exclude" options "git log" takes have learned a companion configuration variable log.excludeDecoration that sits at the lowest priority in the family. * ds/log-exclude-decoration-config: log: add log.excludeDecoration config option log-tree: make ref_filter_match() a helper method
2020-04-16log: add log.excludeDecoration config optionLibravatar Derrick Stolee1-1/+4
In 'git log', the --decorate-refs-exclude option appends a pattern to a string_list. This list is used to prevent showing some refs in the decoration output, or even by --simplify-by-decoration. Users may want to use their refs space to store utility refs that should not appear in the decoration output. For example, Scalar [1] runs a background fetch but places the "new" refs inside the refs/scalar/hidden/<remote>/* refspace instead of refs/<remote>/* to avoid updating remote refs when the user is not looking. However, these "hidden" refs appear during regular 'git log' queries. A similar idea to use "hidden" refs is under consideration for core Git [2]. Add the 'log.excludeDecoration' config option so users can exclude some refs from decorations by default instead of needing to use --decorate-refs-exclude manually. The config value is multi-valued much like the command-line option. The documentation is careful to point out that the config value can be overridden by the --decorate-refs option, even though --decorate-refs-exclude would always "win" over --decorate-refs. Since the 'log.excludeDecoration' takes lower precedence to --decorate-refs, and --decorate-refs-exclude takes higher precedence, the struct decoration_filter needed another field. This led also to new logic in load_ref_decorations() and ref_filter_match(). There are several tests in t4202-log.sh that test the --decorate-refs-(include|exclude) options, so these are extended. Since the expected output is already stored as a file, most tests could simply replace a "--decorate-refs-exclude" option with an in-line config setting. Other tests involve the precedence of the config option compared to command-line options and needed more modification. [1] https://github.com/microsoft/scalar [2] https://lore.kernel.org/git/77b1da5d3063a2404cd750adfe3bb8be9b6c497d.1585946894.git.gitgitgadget@gmail.com/ Helped-by: Junio C Hamano <gister@pobox.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-16log: give --[no-]use-mailmap a more sensible synonym --[no-]mailmapLibravatar Junio C Hamano1-0/+1
The option name "--use-mailmap" looks OK, but it becomes awkward when you have to negate it, i.e. "--no-use-mailmap". I, perhaps with many other users, always try "--no-mailmap" and become unhappy to see it fail. Add an alias "--[no-]mailmap" to remedy this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-06Merge branch 'pb/clarify-line-log-doc'Libravatar Junio C Hamano1-2/+6
Doc update. * pb/clarify-line-log-doc: doc: log, gitk: line-log arguments must exist in starting revision doc: log, gitk: document accepted line-log diff formats
2019-12-26doc: log, gitk: line-log arguments must exist in starting revisionLibravatar Philippe Blain1-1/+2
The line number, regex or offset parameters <start> and <end> in `git log -L <start>,<end>:<file>`, or the function name regex in `git log -L :<funcname>:<file>` must exist in the starting revision, or else the command exits with a fatal error. This is not obvious in the documentation, so add a note to that effect. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-26doc: log, gitk: document accepted line-log diff formatsLibravatar Philippe Blain1-1/+4
Currently the line-log functionality (git log -L) only supports displaying patch output (`-p | --patch`, its default behavior) and suppressing it (`-s | --no-patch`). A check was added in the code to that effect in 5314efaea (line-log: detect unsupported formats, 2019-03-10) but the documentation was not updated. Explicitly mention that `-L` implies `-p`, that patch output can be suppressed using `-s`, and that all other diff formats are not allowed. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-15documentation: mention --no-use-mailmap and log.mailmap false settingLibravatar Ariadne Conill1-1/+1
The log.mailmap setting may be explicitly set to false, which disables the mailmap feature implicity. In practice, doing so is equivalent to always using the previously undocumented --no-use-mailmap option on the command line. Accordingly, we document both the existence of --no-use-mailmap as well as briefly discuss the equivalence of it to log.mailmap=False. Signed-off-by: Ariadne Conill <ariadne@dereferenced.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22Add 'human' date format documentationLibravatar Stephen P. Smith1-0/+4
Display date and time information in a format similar to how people write dates in other contexts. If the year isn't specified then, the reader infers the date is given is in the current year. By not displaying the redundant information, the reader concentrates on the information that is different. The patch reports relative dates based on information inferred from the date on the machine running the git command at the time the command is executed. While the format is more useful to humans by dropping inferred information, there is nothing that makes it actually human. If the 'relative' date format wasn't already implemented then using 'relative' would have been appropriate. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18git-[short]log.txt: unify quoted standalone --Libravatar Martin Ågren1-2/+2
In git-log.txt, we have an instance of \--, which is known to sometimes render badly. This one is even worse than normal though, since ``\-- '' (with or without that trailing space) appears to be entirely broken, both in HTML and manpages, both with AsciiDoc (version 8.6.9) and Asciidoctor (version 1.5.4). Further down in git-log.txt we have a ``--'', which renders good. In git-shortlog.txt, we use "\-- " (including the quotes and the space), which happens to look fairly good. I failed to find any other similar instances. So all in all, we quote a double-dash in three different places and do it differently each time, with various degrees of success. Switch all of these to `--`. This sets the double-dash in monospace and matches what we usually do with example command line usages and options. Note that we drop the trailing space as well, since `-- ` does not render well. These should still be clear enough since just a few lines above each instance, the space is clearly visible in a longer context. Signed-off-by: Martin Ågren <martin.agren@gmail.com>
2018-04-18doc: convert [\--] to [--]Libravatar Martin Ågren1-2/+2
Commit 1c262bb7b (doc: convert \--option to --option, 2015-05-13) explains that we used to need to write \--option to play well with older versions of AsciiDoc, but that we do not support such versions anymore anyway, and that Asciidoctor literally renders \--. With [\--], which is used to denote the optional separator between revisions and paths, Asciidoctor renders the backslash literally. Change all [\--] to [--]. This changes nothing for AsciiDoc version 8.6.9, but is an improvement for Asciidoctor version 1.5.4. We use double-dashes in several list entries (\--::). In my testing, it appears that we do need to use the backslash there, so leave those. Signed-off-by: Martin Ågren <martin.agren@gmail.com>
2017-11-22log: add option to choose which refs to decorateLibravatar Rafael Ascensão1-0/+7
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>
2016-07-11Merge branch 'mj/log-show-signature-conf'Libravatar Junio C Hamano1-0/+4
"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
2016-06-27Merge branch 'tr/doc-tt'Libravatar Junio C Hamano1-2/+2
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
2016-06-24log: add log.showSignature configuration variableLibravatar Mehul Jain1-0/+4
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>
2016-06-08doc: change environment variables formatLibravatar Tom Russello1-2/+2
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>
2016-05-29Merge branch 'rj/log-decorate-auto'Libravatar Junio C Hamano1-3/+5
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
2016-05-27log: document the --decorate=auto optionLibravatar Ramsay Jones1-3/+5
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07log: Update log.follow doc and add to config.txtLibravatar Eric N. Vander Weele1-4/+4
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>
2015-07-09log: add "log.follow" configuration variableLibravatar David Turner1-0/+6
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>
2015-05-05Merge branch 'mm/usage-log-l-can-take-regex'Libravatar Junio C Hamano1-2/+2
Documentation fix. * mm/usage-log-l-can-take-regex: log -L: improve error message on malformed argument Documentation: change -L:<regex> to -L:<funcname>
2015-04-20Documentation: change -L:<regex> to -L:<funcname>Libravatar Matthieu Moy1-2/+2
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>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
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>
2013-12-03Merge branch 'jj/log-doc'Libravatar Junio C Hamano1-26/+25
Mark-up fixes. * jj/log-doc: Documentation/git-log.txt: mark-up fix and minor rephasing Documentation/git-log: update "--log-size" description
2013-11-13Documentation/git-log.txt: mark-up fix and minor rephasingLibravatar Jason St. John1-23/+23
- 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>
2013-11-13Documentation/git-log: update "--log-size" descriptionLibravatar Jason St. John1-5/+5
"--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>
2013-08-06line-range-format.txt: clarify -L:regex usage formLibravatar Eric Sunshine1-2/+0
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>
2013-08-06git-log.txt: place each -L option variation on its own lineLibravatar Eric Sunshine1-1/+2
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>
2013-07-22Merge branch 'mm/diff-no-patch-synonym-to-s'Libravatar Junio C Hamano1-4/+4
"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
2013-07-17Documentation/git-log.txt: capitalize section namesLibravatar Matthieu Moy1-4/+4
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>
2013-07-17git-log.txt: fix typesetting of example "git-log -L" invocationLibravatar Eric Sunshine1-1/+1
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>
2013-06-26Merge branch 'ph/builtin-srcs-are-in-subdir-these-days'Libravatar Junio C Hamano1-2/+2
* ph/builtin-srcs-are-in-subdir-these-days: fix "builtin-*" references to be "builtin/*"
2013-06-18fix "builtin-*" references to be "builtin/*"Libravatar Phil Hord1-2/+2
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>
2013-06-02Merge branch 'tr/line-log'Libravatar Junio C Hamano1-0/+18
* 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
2013-04-22git-log(1): remove --full-line-diff descriptionLibravatar Thomas Rast1-4/+0
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>
2013-04-21git-log.txt: rewrite note on why "--" may be requiredLibravatar Ramkumar Ramachandra1-2/+2
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>
2013-04-21git-log.txt: generalize <since>..<until>Libravatar Ramkumar Ramachandra1-7/+9
'<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>
2013-04-21git-log.txt: order OPTIONS properly; move <since>..<until>Libravatar Ramkumar Ramachandra1-7/+7
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>
2013-04-21line-log: fix documentation formattingLibravatar Junio C Hamano1-3/+2
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>
2013-03-28log -L: :pattern:file syntax to find by funcnameLibravatar Thomas Rast1-5/+6
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>
2013-03-28Implement line-history search (git log -L)Libravatar Thomas Rast1-0/+22
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>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>