summaryrefslogtreecommitdiff
path: root/Documentation/rev-list-options.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-07-22Merge branch 'mm/diff-no-patch-synonym-to-s'Libravatar Junio C Hamano1-3/+0
"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: move description of -s, --no-patch to diff-options.txtLibravatar Matthieu Moy1-4/+0
Technically, "-s, --no-patch" is implemented in diff.c ("git diff --no-patch" is essentially useless, but valid). From the user point of view, this allows the documentation to show up in "git show --help", which is one of the most useful use of the option. While we're there, add a sentence explaining why the option can be useful. 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-17diff: allow --no-patch as synonym for -sLibravatar Matthieu Moy1-0/+1
This follows the usual convention of having a --no-foo option to negate --foo. 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-01Merge branch 'jc/topo-author-date-sort'Libravatar Junio C Hamano1-0/+4
"git log" learned the "--author-date-order" option, with which the output is topologically sorted and commits in parallel histories are shown intermixed together based on the author timestamp. * jc/topo-author-date-sort: t6003: add --author-date-order test topology tests: teach a helper to set author dates as well t6003: add --date-order test topology tests: teach a helper to take abbreviated timestamps t/lib-t6000: style fixes log: --author-date-order sort-in-topological-order: use prio-queue prio-queue: priority queue of pointers to structs toposort: rename "lifo" field
2013-06-11log: --author-date-orderLibravatar Junio C Hamano1-0/+4
Sometimes people would want to view the commits in parallel histories in the order of author dates, not committer dates. Teach "topo-order" sort machinery to do so, using a commit-info slab to record the author dates of each commit, and prio-queue to sort them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16simplify-merges: drop merge from irrelevant side branchLibravatar Kevin Bracey1-13/+21
Reimplement commit 4b7f53da on top of the new simplify-merges infrastructure, tightening the condition to only consider root parents; the original version incorrectly dropped parents that were TREESAME to anything. Original log message follows. The merge simplification rule stated in 6546b59 (revision traversal: show full history with merge simplification, 2008-07-31) still treated merge commits too specially. Namely, in a history with this shape: ---o---o---M / x---x---x where three 'x' were on a history completely unrelated to the main history 'o' and do not touch any of the paths we are following, we still said that after simplifying all of the parents of M, 'x' (which is the leftmost 'x' that rightmost 'x simplifies down to) and 'o' (which would be the last commit on the main history that touches the paths we are following) are independent from each other, and both need to be kept. That is incorrect; when the side branch 'x' never touches the paths, it should be removed to allow M to simplify down to the last commit on the main history that touches the paths. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16simplify-merges: never remove all TREESAME parentsLibravatar Kevin Bracey1-1/+2
When simplifying an odd merge, such as one that used "-s ours", we may find ourselves TREESAME to apparently redundant parents. Prevent simplify_merges() from removing every TREESAME parent; if this would happen reinstate the first TREESAME parent - the one that the default log would have followed. This avoids producing a totally disjoint history from the default log when the default log is a better explanation of the end result, and aids visualisation of odd merges. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: Make --full-history consider more mergesLibravatar Kevin Bracey1-3/+3
History simplification previously always treated merges as TREESAME if they were TREESAME to any parent. While this was consistent with the default behaviour, this could be extremely unhelpful when searching detailed history, and could not be overridden. For example, if a merge had ignored a change, as if by "-s ours", then: git log -m -p --full-history -Schange file would successfully locate "change"'s addition but would not locate the merge that resolved against it. Futher, simplify_merges could drop the actual parent that a commit was TREESAME to, leaving it as a normal commit marked TREESAME that isn't actually TREESAME to its remaining parent. Now redefine a commit's TREESAME flag to be true only if a commit is TREESAME to _all_ of its parents. This doesn't affect either the default simplify_history behaviour (because partially TREESAME merges are turned into normal commits), or full-history with parent rewriting (because all merges are output). But it does affect other modes. The clearest difference is that --full-history will show more merges - sufficient to ensure that -m -p --full-history log searches can really explain every change to the file, including those changes' ultimate fate in merges. Also modify simplify_merges to recalculate TREESAME after removing a parent. This is achieved by storing per-parent TREESAME flags on the initial scan, so the combined flag can be easily recomputed. This fixes some t6111 failures, but creates a couple of new ones - we are now showing some merges that don't need to be shown. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16Documentation: avoid "uninteresting"Libravatar Kevin Bracey1-2/+2
The documentation of --boundary uses the term "uninteresting", which is not used or defined anywhere else in the documentation. This is unhelpful and confusing to anyone who hasn't seen the UNINTERESTING flag in the source code. Change to use "excluded", as per revisions.txt. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16rev-list-options.txt: correct TREESAME for PLibravatar Kevin Bracey1-2/+1
In the example given, P is not TREESAME to E. This doesn't affect the current result, but it will matter when we change behaviour. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-2/+2
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-09log --grep: accept --basic-regexp and --perl-regexpLibravatar Junio C Hamano1-0/+10
When we added the "--perl-regexp" option (or "-P") to "git grep", we should have done the same for the commands in the "git log" family, but somehow we forgot to do so. This corrects it, but we will reserve the short-and-sweet "-P" option for something else for now. Also introduce the "--basic-regexp" option for completeness, so that the "last one wins" principle can be used to defeat an earlier -E option, e.g. "git log -E --basic-regexp --grep='<bre>'". Note that it cannot have the short "-G" option as the option is to grep in the patch text in the context of "log" family. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29revision: make --grep search in notes too if shownLibravatar Nguyễn Thái Ngọc Duy1-0/+3
Notes are shown after commit body. From user perspective it looks pretty much like commit body and they may assume --grep would search in that part too. Make it so. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29log --grep-reflog: reject the option without -gLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29revision: add --grep-reflog to filter commits by reflog messagesLibravatar Nguyễn Thái Ngọc Duy1-0/+8
Similar to --author/--committer which filters commits by author and committer header fields. --grep-reflog adds a fake "reflog" header to commit and a grep filter to search on that line. All rules to --author/--committer apply except no timestamp stripping. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18Merge branch 'jc/maint-log-grep-all-match'Libravatar Junio C Hamano1-5/+18
Fix a long-standing bug in "git log --grep" when multiple "--grep" are used together with "--all-match" and "--author" or "--committer". * jc/maint-log-grep-all-match: t7810-grep: test --all-match with multiple --grep and --author options t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test multiple --author with --all-match t7810-grep: test multiple --grep with and without --all-match t7810-grep: bring log --grep tests in common form grep.c: mark private file-scope symbols as static log: document use of multiple commit limiting options log --grep/--author: honor --all-match honored for multiple --grep patterns grep: show --debug output only once grep: teach --debug option to dump the parse tree
2012-09-14log: document use of multiple commit limiting optionsLibravatar Junio C Hamano1-5/+18
Generally speaking, using more options will further narrow the selection, but there are a few exceptions. Document them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-12Merge branch 'nd/log-n-doc'Libravatar Junio C Hamano1-1/+2
* nd/log-n-doc: doc: move rev-list option -<n> from git-log.txt to rev-list-options.txt
2012-09-10Merge branch 'mz/cherry-pick-cmdline-order'Libravatar Junio C Hamano1-4/+8
"git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. * mz/cherry-pick-cmdline-order: cherry-pick/revert: respect order of revisions to pick demonstrate broken 'git cherry-pick three one two' teach log --no-walk=unsorted, which avoids sorting
2012-09-06doc: move rev-list option -<n> from git-log.txt to rev-list-options.txtLibravatar Nguyễn Thái Ngọc Duy1-1/+2
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>
2012-08-30teach log --no-walk=unsorted, which avoids sortingLibravatar Martin von Zweigbergk1-3/+8
When 'git log' is passed the --no-walk option, no revision walk takes place, naturally. Perhaps somewhat surprisingly, however, the provided revisions still get sorted by commit date. So e.g 'git log --no-walk HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result (unless the two revisions share the commit date, in which case they will retain the order given on the command line). As the commit that introduced --no-walk (8e64006 (Teach revision machinery about --no-walk, 2007-07-24)) points out, the sorting is intentional, to allow things like git log --abbrev-commit --pretty=oneline --decorate --all --no-walk to show all refs in order by commit date. But there are also other cases where the sorting is not wanted, such as <command producing revisions in order> | git log --oneline --no-walk --stdin To accomodate both cases, leave the decision of whether or not to sort up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting to 'sorted' for backward-compatibility reasons. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-22Merge branch 'jc/maint-rev-list-topo-doc'Libravatar Junio C Hamano1-7/+24
It was unclear what "--topo-order" was really about in the documentation. It is not just about "children before parent", but also about "don't mix lineages". * jc/maint-rev-list-topo-doc: rev-list docs: clarify --topo-order description
2012-08-15rev-list docs: clarify --topo-order descriptionLibravatar Junio C Hamano1-7/+24
It was unclear what "--topo-order" was really about in the documentation. It is not just about "children before parent", but also about "don't mix lineages". Reword the description for both "--date-order" and "--topo-order", and add an illustration to it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-14doc: A few minor copy edits.Libravatar Štěpán Němec1-1/+1
- (glossary) the quotes around the Wikipedia URL prevented its linkification in frontends that support it; remove them - (manual) newer version (SHA-1) == following, older == preceding, not the other way around - trivial typo and wording fixes Signed-off-by: Štěpán Němec <stepnem@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25Merge branch 'cn/cherry-pick-range-docs'Libravatar Junio C Hamano1-0/+1
The command line argument of "git cherry-pick maint master..next" is just an ordinary revision range, which is unintuitive and at least deserves documentation. * cn/cherry-pick-range-docs: git-cherry-pick.txt: clarify the use of revision range notation Documentation: --no-walk is no-op if range is specified
2012-06-15Documentation: --no-walk is no-op if range is specifiedLibravatar Carlos Martín Nieto1-0/+1
The existing description can be misleading and cause the reader to think that --no-walk will do something if they specify a range in the command line instead of a set of revs. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-3/+3
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>
2012-02-28Documentation: use {asterisk} in rev-list-options.txt when neededLibravatar Carlos Martín Nieto1-6/+6
Text between two '*' is emphasized in AsciiDoc and makes explanations in rev-list-options.txt on glob-related options very confusing, as the rendered text would be missing two asterisks and the text between them would be emphasized instead. Use '{asterisk}' where needed to make them show up as asterisks in the rendered text. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-22Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: doc/fast-import: clarify notemodify command Documentation: minor grammatical fix in rev-list-options.txt Documentation: git-filter-branch honors replacement refs remote-curl: Add a format check to parsing of info/refs git-config: Remove extra whitespaces
2011-07-22Documentation: minor grammatical fix in rev-list-options.txtLibravatar Jack Nagel1-1/+1
Signed-off-by: Jack Nagel <jacknagel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-29Merge branch 'jn/maint-doc-dashdash' into jn/doc-dashdashLibravatar Junio C Hamano1-1/+1
* jn/maint-doc-dashdash: Documentation: quote double-dash for AsciiDoc
2011-06-29Documentation: quote double-dash for AsciiDocLibravatar Jonathan Nieder1-1/+1
AsciiDoc versions since 5.0.6 treat a double-dash surrounded by spaces (outside of verbatim environments) as a request to insert an em dash. Such versions also treat the three-character sequence "\--", when not followed by another dash, as a request to insert two literal minus signs. Thus from time to time there have been patches to add backslashes to AsciiDoc markup to escape double-dashes that are meant to be represent '--' characters used literally on the command line; see v1.4.0-rc1~174, Fix up docs where "--" isn't displayed correctly, 2006-05-05, for example. AsciiDoc 6.0.3 (2005-04-20) made life harder by also treating double-dashes without surrounding whitespace as markup for an em dash, though only when formatting for backends other than the manpages (e.g., HTML). Many pages needed to be changed to use a backslash before the "--" in names of command-line flags like "--add" (see v0.99.6~37, Update tutorial, 2005-08-30). AsciiDoc 8.3.0 (2008-11-29) refined the em-dash rule to avoid that requirement. Double-dashes without surrounding spaces are not rendered as em dashes any more unless bordered on both sides by alphanumeric characters. The unescaped markup for option names (e.g., "--add") works fine, and many instances of this style have leaked into Documentation/; git's HTML documentation contains many spurious em dashes when formatted by an older toolchain. (This patch will not change that.) The upshot: "--" as an isolated word and in phrases like "git web--browse" must be escaped if it is not to be rendered as an em dash by current asciidoc. Use "\--" to avoid such misformatting in sentences in which "--" represents a literal double-minus command line argument that separates options and revs from pathspecs, and use "{litdd}" in cases where the double-dash is embedded in the command name. The latter is just for consistency with v1.7.3-rc0~13^2 (Work around em-dash handling in newer AsciiDoc, 2010-08-23). List of lines to fix found by grepping manpages for "(em". Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Junio C Hamano <gitster@pobox.com> Improved-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-19show: --ignore-missingLibravatar Junio C Hamano1-0/+4
Instead of barfing, simply ignore bad object names seen in the input. This is useful when reading from "git notes list" output that may refer to objects that have already been garbage collected. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-26rev-list --count: separate count for --cherry-markLibravatar Michael J Gruber1-1/+4
When --count is used with --cherry-mark, omit the patch equivalent commits from the count for left and right commits and print the count of equivalent commits separately. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04Merge branch 'jc/rev-list-options-fix'Libravatar Junio C Hamano1-2/+2
* jc/rev-list-options-fix: "log --cherry-pick" documentation regression fix
2011-04-01"log --cherry-pick" documentation regression fixLibravatar Junio C Hamano1-2/+2
Earlier f98fd43 (git-log.txt,rev-list-options.txt: put option blocks in proper order, 2011-03-08) moved the text around in the documentation for options in the rev-list family of commands such as "log". Consequently, the description of the --cherry-pick option appears way above the description of the --left-right option now. But the description of the --cherry-pick option still refers to the example for the --left-right option, like this: ... with --left-right, like the example ABOVE in the description of that option. Rephrase it to clarify that we are making a forward reference. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-26Merge branch 'mg/rev-list-n-parents'Libravatar Junio C Hamano1-2/+17
* mg/rev-list-n-parents: tests: avoid nonportable {foo,bar} glob rev-list --min-parents,--max-parents: doc, test and completion revision.c: introduce --min-parents and --max-parents options t6009: use test_commit() from test-lib.sh
2011-03-23rev-list --min-parents,--max-parents: doc, test and completionLibravatar Michael J Gruber1-2/+17
This also adds test for "--merges" and "--no-merges" which we did not have so far. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22Merge branch 'mg/rev-list-one-side-only'Libravatar Junio C Hamano1-0/+26
* mg/rev-list-one-side-only: git-log: put space after commit mark t6007: test rev-list --cherry log --cherry: a synonym rev-list: documentation and test for --cherry-mark revision.c: introduce --cherry-mark rev-list/log: factor out revision mark generation rev-list: --left/right-only are mutually exclusive rev-list: documentation and test for --left/right-only t6007: Make sure we test --cherry-pick revlist.c: introduce --left/right-only for unsymmetric picking
2011-03-09git-log.txt,rev-list-options.txt: put option blocks in proper orderLibravatar Michael J Gruber1-155/+155
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>
2011-03-09log --cherry: a synonymLibravatar Michael J Gruber1-0/+8
At the porcelain level, because by definition there are many more contributors than integrators, it makes sense to give a handy short-hand for --right-only used with --cherry-mark and --no-merges. Make it so. In other words, this provides "git cherry with rev-list interface". Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09rev-list: documentation and test for --cherry-markLibravatar Michael J Gruber1-0/+5
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08git-log.txt,rev-list-options.txt: -n/--max-count is commit limitingLibravatar Michael J Gruber1-1/+2
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>
2011-03-08rev-list-options.txt: typo fixLibravatar Michael J Gruber1-1/+1
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21rev-list: documentation and test for --left/right-onlyLibravatar Michael J Gruber1-0/+13
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'mm/phrase-remote-tracking'Libravatar Junio C Hamano1-1/+1
* mm/phrase-remote-tracking: git-branch.txt: mention --set-upstream as a way to change upstream configuration user-manual: remote-tracking can be checked out, with detached HEAD user-manual.txt: explain better the remote(-tracking) branch terms Change incorrect "remote branch" to "remote tracking branch" in C code Change incorrect uses of "remote branch" meaning "remote-tracking" Change "tracking branch" to "remote-tracking branch" everyday.txt: change "tracking branch" to "remote-tracking branch" Change remote tracking to remote-tracking in non-trivial places Replace "remote tracking" with "remote-tracking" Better "Changed but not updated" message in git-status
2010-11-17Document that rev-list --graph triggers parent rewriting.Libravatar Yann Dirson1-0/+2
This may help to understand why --graph causes more comments to be selected. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09Documentation: document show -sLibravatar Jonathan Nieder1-0/+3
Git's diff machinery has supported a -s (silence diff output) option as far back as v0.99~900 (Silent flag for show-diff, 2005-04-13), but the option is only advertised in an odd corner of the git diff-tree manual. The main use is to retrieve basic metadata about a commit: git show -s rev Explain this in the 'git log' manual and provide an example in the 'git show' examples section. This is kind of a cop-out, since it would be more useful to explain it in the 'git show' manual proper, which says: The command takes options applicable to the git diff-tree command to control how the changes the commit introduces are shown. This manual page describes only the most frequently used options. Fixing that is a larger task for another day. Reported-by: Will Hall <will@gnatter.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Replace "remote tracking" with "remote-tracking"Libravatar Matthieu Moy1-1/+1
"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>
2010-10-08Use parentheses and `...' where appropriateLibravatar Štěpán Němec1-1/+1
Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>