summaryrefslogtreecommitdiff
path: root/Documentation/rev-list-options.txt
AgeCommit message (Collapse)AuthorFilesLines
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano1-1/+1
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-04-03Merge branch 'nd/log-show-linear-break'Libravatar Junio C Hamano1-0/+7
Attempts to show where a single-strand-of-pearls break in "git log" output. * nd/log-show-linear-break: log: add --show-linear-break to help see non-linear history object.h: centralize object flag allocation
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-25log: add --show-linear-break to help see non-linear historyLibravatar Nguyễn Thái Ngọc Duy1-0/+7
Option explanation is in rev-list-options.txt. The interaction with -z is left undecided. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-27Merge branch 'jk/pack-bitmap'Libravatar Junio C Hamano1-0/+8
Borrow the bitmap index into packfiles from JGit to speed up enumeration of objects involved in a commit range without having to fully traverse the history. * jk/pack-bitmap: (26 commits) ewah: unconditionally ntohll ewah data ewah: support platforms that require aligned reads read-cache: use get_be32 instead of hand-rolled ntoh_l block-sha1: factor out get_be and put_be wrappers do not discard revindex when re-preparing packfiles pack-bitmap: implement optional name_hash cache t/perf: add tests for pack bitmaps t: add basic bitmap functionality tests count-objects: recognize .bitmap in garbage-checking repack: consider bitmaps when performing repacks repack: handle optional files created by pack-objects repack: turn exts array into array-of-struct repack: stop using magic number for ARRAY_SIZE(exts) pack-objects: implement bitmap writing rev-list: add bitmap mode to speed up object lists pack-objects: use bitmaps when packing objects pack-objects: split add_object_entry pack-bitmap: add support for bitmap indexes documentation: add documentation for the bitmap format ewah: compressed bitmap implementation ...
2013-12-30rev-list: add bitmap mode to speed up object listsLibravatar Vicent Marti1-0/+8
The bitmap reachability index used to speed up the counting objects phase during `pack-objects` can also be used to optimize a normal rev-list if the only thing required are the SHA1s of the objects during the list (i.e., not the path names at which trees and blobs were found). Calling `git rev-list --objects --use-bitmap-index [committish]` will perform an object iteration based on a bitmap result instead of actually walking the object graph. These are some example timings for `torvalds/linux` (warm cache, best-of-five): $ time git rev-list --objects master > /dev/null real 0m34.191s user 0m33.904s sys 0m0.268s $ time git rev-list --objects --use-bitmap-index master > /dev/null real 0m1.041s user 0m0.976s sys 0m0.064s Likewise, using `git rev-list --count --use-bitmap-index` will speed up the counting operation by building the resulting bitmap and performing a fast popcount (number of bits set on the bitmap) on the result. Here are some sample timings of different ways to count commits in `torvalds/linux`: $ time git rev-list master | wc -l 399882 real 0m6.524s user 0m6.060s sys 0m3.284s $ time git rev-list --count master 399882 real 0m4.318s user 0m4.236s sys 0m0.076s $ time git rev-list --use-bitmap-index --count master 399882 real 0m0.217s user 0m0.176s sys 0m0.040s This also respects negative refs, so you can use it to count a slice of history: $ time git rev-list --count v3.0..master 144843 real 0m1.971s user 0m1.932s sys 0m0.036s $ time git rev-list --use-bitmap-index --count v3.0..master real 0m0.280s user 0m0.220s sys 0m0.056s Though note that the closer the endpoints, the less it helps. In the traversal case, we have fewer commits to cross, so we take less time. But the bitmap time is dominated by generating the pack revindex, which is constant with respect to the refs given. Note that you cannot yet get a fast --left-right count of a symmetric difference (e.g., "--count --left-right master...topic"). The slow part of that walk actually happens during the merge-base determination when we parse "master...topic". Even though a count does not actually need to know the real merge base (it only needs to take the symmetric difference of the bitmaps), the revision code would require some refactoring to handle this case. Additionally, a `--test-bitmap` flag has been added that will perform the same rev-list manually (i.e. using a normal revwalk) and using bitmaps, and verify that the results are the same. This can be used to exercise the bitmap code, and also to verify that the contents of the .bitmap file are sane. Signed-off-by: Vicent Marti <tanoku@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05Merge branch 'jc/ref-excludes'Libravatar Junio C Hamano1-0/+15
People often wished a way to tell "git log --branches" (and "git log --remotes --not --branches") to exclude some local branches from the expansion of "--branches" (similarly for "--tags", "--all" and "--glob=<pattern>"). Now they have one. * jc/ref-excludes: rev-parse: introduce --exclude=<glob> to tame wildcards rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API rev-list --exclude: tests document --exclude option revision: introduce --exclude=<glob> to tame wildcards
2013-12-03Merge branch 'jj/rev-list-options-doc'Libravatar Junio C Hamano1-156/+87
Mark-up and grammo fixes. * jj/rev-list-options-doc: Documentation/rev-list-options.txt: fix some grammatical issues and typos Documentation/rev-list-options.txt: fix mark-up
2013-11-18Documentation/rev-list-options.txt: fix some grammatical issues and typosLibravatar Jason St. John1-13/+14
Various fixes: - fix typos (e.g. "show" -> "shown") - use "regular expression(s)" instead of "regexp" where appropriate - reword some sentences for easier reading - fix/improve some grammatical issues (e.g. comma usage) - add missing articles (e.g. "the") - change "E-mail" to "email" Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18Documentation/rev-list-options.txt: fix mark-upLibravatar Jason St. John1-148/+78
Some the labeled list entries have a blank line between the label and the body text, and some don't. Use the latter style for consistency; incidentally, syntax highlighting in Vim works better if there is no blank line there. Typeset literal options, commands, and path names in monospace. When using `literal string` mark-up to do so, there is no need to escape AsciiDoc special characters with backslashes, so make sure we don't do so. Replace some double quotes with proper AsciiDoc quotes (e.g. ``foo''). Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-12Correct word usage of "timezone" in "Documentation" directoryLibravatar Jason St. John1-2/+2
"timezone" is two words, not one (i.e. "time zone" is correct). Correct this in these files: -- date-formats.txt -- git-blame.txt -- git-cvsimport.txt -- git-fast-import.txt -- git-svn.txt -- gitweb.conf.txt -- rev-list-options.txt Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-01document --exclude optionLibravatar Johannes Sixt1-0/+15
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Sync with maint to grab trivial doc fixesLibravatar Junio C Hamano1-1/+1
* maint: fix typo in documentation of git-svn Documentation/rev-list-options: add missing word in --*-parents log doc: the argument to --encoding is not optional
2013-08-05Documentation/rev-list-options: add missing word in --*-parentsLibravatar Torstein Hegge1-1/+1
A commit has "parent commits" or "parents", not "commits". Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22typofix: documentationLibravatar Ondřej Bílka1-1/+1
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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