Commit Graph

92 Commits

Author SHA1 Message Date
Junio C Hamano
727b6fc3ed log --grep: accept --basic-regexp and --perl-regexp
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-10-09 23:21:30 -07:00
Nguyễn Thái Ngọc Duy
38cfe915bf revision: make --grep search in notes too if shown
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-29 12:15:05 -07:00
Junio C Hamano
baa6378ff2 log --grep-reflog: reject the option without -g
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29 12:07:04 -07:00
Nguyễn Thái Ngọc Duy
72fd13f71c revision: add --grep-reflog to filter commits by reflog messages
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-29 11:41:14 -07:00
Junio C Hamano
3d7535e424 Merge branch 'jc/maint-log-grep-all-match'
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-18 14:37:54 -07:00
Junio C Hamano
a23e3138cb log: document use of multiple commit limiting options
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-14 10:23:47 -07:00
Junio C Hamano
2cdfb602a4 Merge branch 'nd/log-n-doc'
* nd/log-n-doc:
  doc: move rev-list option -<n> from git-log.txt to rev-list-options.txt
2012-09-12 14:21:55 -07:00
Junio C Hamano
c2b927932d Merge branch 'mz/cherry-pick-cmdline-order'
"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-10 15:42:55 -07:00
Nguyễn Thái Ngọc Duy
70c2a258c6 doc: move rev-list option -<n> from git-log.txt to rev-list-options.txt
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-09-06 13:26:50 -07:00
Martin von Zweigbergk
ca92e59e30 teach log --no-walk=unsorted, which avoids sorting
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-30 12:26:50 -07:00
Junio C Hamano
4def968e14 Merge branch 'jc/maint-rev-list-topo-doc'
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-22 11:53:20 -07:00
Junio C Hamano
3f0350ccd5 rev-list docs: clarify --topo-order description
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-08-15 13:04:20 -07:00
Štěpán Němec
edfbbf7eea doc: A few minor copy edits.
- (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-07-14 22:32:28 -07:00
Junio C Hamano
a913b56fcb Merge branch 'cn/cherry-pick-range-docs'
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-25 11:25:38 -07:00
Carlos Martín Nieto
42939f1a24 Documentation: --no-walk is no-op if range is specified
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-06-15 10:41:37 -07:00
Jeff King
6cf378f0cb docs: stop using asciidoc no-inline-literal
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-04-26 13:19:06 -07:00
Carlos Martín Nieto
e34bb2e7fd Documentation: use {asterisk} in rev-list-options.txt when needed
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>
2012-02-28 13:17:14 -08:00
Junio C Hamano
ed16d0dbf1 Merge branch 'maint'
* 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-22 13:58:46 -07:00
Jack Nagel
df6b0cad5f Documentation: minor grammatical fix in rev-list-options.txt
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-22 10:38:59 -07:00
Junio C Hamano
347231f735 Merge branch 'jn/maint-doc-dashdash' into jn/doc-dashdash
* jn/maint-doc-dashdash:
  Documentation: quote double-dash for AsciiDoc
2011-06-29 09:25:51 -07:00
Jonathan Nieder
565e135a1e Documentation: quote double-dash for AsciiDoc
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-06-29 09:24:26 -07:00
Junio C Hamano
cc243c3ceb show: --ignore-missing
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-05-19 10:55:54 -07:00
Michael J Gruber
b388e14b89 rev-list --count: separate count for --cherry-mark
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-26 13:13:20 -07:00
Junio C Hamano
2c320e71bf Merge branch 'jc/rev-list-options-fix'
* jc/rev-list-options-fix:
  "log --cherry-pick" documentation regression fix
2011-04-04 10:55:38 -07:00
Junio C Hamano
3add01bbf1 "log --cherry-pick" documentation regression fix
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-04-01 15:14:38 -07:00
Junio C Hamano
bf0c5bbe25 Merge branch 'mg/rev-list-n-parents'
* 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-26 20:13:17 -07:00
Michael J Gruber
6a6ebded7f rev-list --min-parents,--max-parents: doc, test and completion
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-23 10:20:24 -07:00
Junio C Hamano
aeb2aaa771 Merge branch 'mg/rev-list-one-side-only'
* 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-22 21:38:50 -07:00
Michael J Gruber
f98fd43675 git-log.txt,rev-list-options.txt: put option blocks in proper order
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-09 15:15:52 -08:00
Michael J Gruber
94f605ec07 log --cherry: a synonym
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-09 13:50:54 -08:00
Michael J Gruber
cb56e3093a rev-list: documentation and test for --cherry-mark
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 13:50:54 -08:00
Michael J Gruber
190767f6c1 git-log.txt,rev-list-options.txt: -n/--max-count is commit limiting
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-08 11:59:43 -08:00
Michael J Gruber
841d81180e rev-list-options.txt: typo fix
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08 11:56:37 -08:00
Michael J Gruber
59c8afdf47 rev-list: documentation and test for --left/right-only
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21 16:34:05 -08:00
Junio C Hamano
786f174dab Merge branch 'mm/phrase-remote-tracking'
* 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-24 15:55:05 -08:00
Yann Dirson
6a6c54bafe Document that rev-list --graph triggers parent rewriting.
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-17 13:16:48 -08:00
Jonathan Nieder
60aa9cf8f3 Documentation: document show -s
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-09 09:42:57 -08:00
Matthieu Moy
0e615b252f Replace "remote tracking" with "remote-tracking"
"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-11-03 09:19:04 -07:00
Štěpán Němec
0adda9362a Use parentheses and `...' where appropriate
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-08 12:31:07 -07:00
Štěpán Němec
62b4698e55 Use angles for placeholders consistently
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-08 12:29:52 -07:00
Michael J Gruber
e14712c9e6 rev-list-options: clarify --parents and --children
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-09-30 09:38:47 -07:00
Jonathan Nieder
b9190e7913 Documentation: do not convert ... operator to ellipses
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-08-20 14:16:51 -07:00
Junio C Hamano
6296062285 Merge branch 'tr/rev-list-count'
* 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-30 11:55:38 -07:00
Thomas Rast
f69c501832 rev-list: introduce --count option
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-12 09:39:06 -07:00
Johan Herland
57456ef459 Documentation/rev-list-options.txt: Explain --ancestry-path
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-06 10:16:31 -07:00
Johan Herland
f70d0586d6 Documentation/rev-list-options.txt: Fix missing line in example history graph
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-06-06 10:16:30 -07:00
Junio C Hamano
797d44343c Merge branch 'pb/log-first-parent-p-m'
* 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-03-24 16:25:39 -07:00
Jeff King
cc1b8d8bc6 docs: don't talk about $GIT_DIR/refs/ everywhere
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-17 21:40:09 -08:00
Petr Baudis
88d9d45d07 git log -p -m: document -m and honor --first-parent
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-02-12 11:32:23 -08:00
Ralf Wildenhues
6a5d0b0a90 Fix typos in technical documentation.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-31 10:24:53 -08:00