summaryrefslogtreecommitdiff
path: root/Documentation/rev-list-options.txt
AgeCommit message (Collapse)AuthorFilesLines
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>
2010-10-08Use angles for placeholders consistentlyLibravatar Štěpán Němec1-8/+8
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>
2010-09-30rev-list-options: clarify --parents and --childrenLibravatar Michael J Gruber1-4/+4
Make it clearer that --parents resp. --children list the parent resp. child commits next to each commit, so that I understand next time. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-20Documentation: do not convert ... operator to ellipsesLibravatar Jonathan Nieder1-1/+1
The symmetric difference or merge-base operator ... as used by rev-list and diff is actually three period characters. If it gets replaced by an ellipsis glyph in the manual, that would stop readers from copying and pasting it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'tr/rev-list-count'Libravatar Junio C Hamano1-0/+9
* tr/rev-list-count: bash completion: Support "divergence from upstream" messages in __git_ps1 rev-list: introduce --count option Conflicts: contrib/completion/git-completion.bash
2010-06-12rev-list: introduce --count optionLibravatar Thomas Rast1-0/+9
Add a --count option that, instead of actually listing the commits, merely counts them. This is mostly geared towards script use, and to this end it acts specially when used with --left-right: it outputs the left and right counts separately. Previously, scripts would have to run a shell loop or small inline script over to achieve the same. (Without --left-right, a simple |wc -l does the job.) Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-06Documentation/rev-list-options.txt: Explain --ancestry-pathLibravatar Johan Herland1-2/+48
Add a short paragraph explaining --ancestry-path, followed by a more detailed example. This mirrors how the other history simplification options are documented. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-06Documentation/rev-list-options.txt: Fix missing line in example history graphLibravatar Johan Herland1-1/+1
In the detailed explanation of how the revision machinery does history simplification, the current text presents an example history and explains how various options of the revision machinery affect the resulting list of commits. The first simplification mode mentioned is the default mode, in which a number of commits is omitted from the example graph according to the history simplification rules. The text states (among other things) that commit "C was considered via N, but is TREESAME", and therefore omitted. However, the accompanying graph does not list the effect on the implicit parentage, i.e. that commit I takes C's place as a parent of N. Running 'git rev-list --parents P' does indeed list I as a second parent of N, and the accompanying graph should therefore also show this line. Signed-off-by: Johan Herland <johan@herland.net> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-24Merge branch 'pb/log-first-parent-p-m'Libravatar Junio C Hamano1-2/+11
* pb/log-first-parent-p-m: show --first-parent/-m: do not default to --cc show -c: show patch text revision: introduce setup_revision_opt t4013: add tests for log -p -m --first-parent git log -p -m: document -m and honor --first-parent
2010-02-17docs: don't talk about $GIT_DIR/refs/ everywhereLibravatar Jeff King1-11/+11
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we may also consult the packed refs mechanism. These days we tend to treat the "refs hierarchy" as more of an abstract namespace that happens to be represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at worst it can confuse users who then look in $GIT_DIR/refs and find that it is missing some of the refs they expected to see. This patch drops most uses of "$GIT_DIR/refs/*", changing them into just "refs/*", under the assumption that users can handle the concept of an abstract refs namespace. There are a few things to note: - most cases just dropped the $GIT_DIR/ portion. But for cases where that left _just_ the word "refs", I changed it to "refs/" to help indicate that it was a hierarchy. I didn't do the same for longer paths (e.g., "refs/heads" remained, instead of becoming "refs/heads/"). - in some cases, no change was made, as the text was explicitly about unpacked refs (e.g., the discussion in git-pack-refs). - In some cases it made sense instead to note the existence of packed refs (e.g., in check-ref-format and rev-parse). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-12git log -p -m: document -m and honor --first-parentLibravatar Petr Baudis1-2/+11
git log -p -m is used to show one merge entry per parent, with an appropriate diff; this can be useful when examining histories where full set of changes introduced by a merged branch is interesting, not only the conflicts. This patch properly documents the -m switch, which has so far been mentioned only as a fairly special diff-tree flag. It also makes the code show full patch entry only for the first parent when --first-parent is used. Thus: git log -p -m --first-parent will show the history from the "main branch perspective", while also including full diff of changes introduced by other merged in branches. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-31Fix typos in technical documentation.Libravatar Ralf Wildenhues1-4/+4
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20rev-parse --branches/--tags/--remotes=patternLibravatar Ilari Liusvaara1-6/+12
Since local branch, tags and remote tracking branch namespaces are most often used, add shortcut notations for globbing those in manner similar to --glob option. With this, one can express the "what I have but origin doesn't?" as: 'git log --branches --not --remotes=origin' Original-idea-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20rev-parse --globLibravatar Ilari Liusvaara1-0/+7
Add --glob=<glob-pattern> option to rev-parse and everything that accepts its options. This option matches all refs that match given shell glob pattern (complete with some DWIM logic). Example: 'git log --branches --not --glob=remotes/origin' To show what you have that origin doesn't. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-24Documentation: update descriptions of revision options related to '--bisect'Libravatar Christian Couder1-12/+27
In commit ad3f9a7 (Add '--bisect' revision machinery argument) the '--bisect' option was added to easily pass bisection refs to commands using the revision machinery. This patch updates the documentation of the related options to describe the new behavior. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20Make --stdin option to "log" family read also pathspecsLibravatar Junio C Hamano1-1/+3
Similar to the command line arguments, after giving zero or more revs, you can feed a line "--" and then feed pathspecs one at a time. With this ( echo ^maint echo -- echo Documentation ) | git log --stat --oneline --stdin master -- t lists commits that touch Documentation/ or t/ between maint and master. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20Teach --stdin option to "log" familyLibravatar Junio C Hamano1-1/+1
Move the logic to read revs from standard input that rev-list knows about from it to revision machinery, so that all the users of setup_revisions() can feed the list of revs from the standard input when "--stdin" is used on the command line. Allow some users of the revision machinery that want different semantics from the "--stdin" option to disable it by setting an option in the rev_info structure. This also cleans up the kludge made to bundle.c via cut and paste. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-13Document 'git (rev-list|log) --merges'Libravatar SZEDER Gábor1-0/+4
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>