Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 7月, 2015 1 次提交
  3. 21 4月, 2015 1 次提交
  5. 14 3月, 2015 1 次提交
  7. 14 11月, 2013 2 次提交
  9. 07 8月, 2013 2 次提交
    • E
      line-range-format.txt: clarify -L:regex usage form · 0ddd4719
      由 Eric Sunshine 提交于 
      blame/log documentation describes -L option as:

  -L<start>,<end>
  -L:<regex>

  <start> and <end> can take one of these forms:

    * number
    * /regex/
    * +offset or -offset
    * :regex

which is incorrect and confusing since :regex is not one of the valid
forms of <start> or <end>; in fact, it must be -L's lone argument.

Clarify by discussing :<regex> at the same indentation level as "<start>
and <end>...":

  -L<start>,<end>
  -L:<regex>

  <start> and <end> can take one of these forms:

    * number
    * /regex/
    * +offset or -offset

  If :<regex> is given in place of <start> and <end> ...
Signed-off-by: NEric Sunshine <sunshine@sunshineco.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0ddd4719
    • E
      git-log.txt: place each -L option variation on its own line · 1e159833
      由 Eric Sunshine 提交于 
      Standard practice in Git documentation is for each variation of an
option (such as: -p / --porcelain) to be placed on its own line in the
OPTIONS table. The -L option does not follow suit. It cuddles "-L
<start>,<end>:<file>" and "-L :<regex>:<file>", separated by a comma.
This is inconsistent and potentially confusing since the comma
separating them is typeset the same as the comma in "<start>,<end>". Fix
this by placing each variation on its own line.
Signed-off-by: NEric Sunshine <sunshine@sunshineco.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1e159833
  11. 18 7月, 2013 2 次提交
  13. 19 6月, 2013 1 次提交
  15. 22 4月, 2013 5 次提交
  17. 29 3月, 2013 2 次提交
    • T
      log -L: :pattern:file syntax to find by funcname · 13b8f68c
      由 Thomas Rast 提交于 
      This new syntax finds a funcname matching /pattern/, and then takes from there
up to (but not including) the next funcname.  So you can say

  git log -L:main:main.c

and it will dig up the main() function and show its line-log, provided
there are no other funcnames matching 'main'.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      13b8f68c
    • T
      Implement line-history search (git log -L) · 12da1d1f
      由 Thomas Rast 提交于 
      This is a rewrite of much of Bo's work, mainly in an effort to split
it into smaller, easier to understand routines.

The algorithm is built around the struct range_set, which encodes a
series of line ranges as intervals [a,b).  This is used in two
contexts:

* A set of lines we are tracking (which will change as we dig through
  history).
* To encode diffs, as pairs of ranges.

The main routine is range_set_map_across_diff().  It processes the
diff between a commit C and some parent P.  It determines which diff
hunks are relevant to the ranges tracked in C, and computes the new
ranges for P.

The algorithm is then simply to process history in topological order
from newest to oldest, computing ranges and (partial) diffs.  At
branch points, we need to merge the ranges we are watching.  We will
find that many commits do not affect the chosen ranges, and mark them
TREESAME (in addition to those already filtered by pathspec limiting).
Another pass of history simplification then gets rid of such commits.

This is wired as an extra filtering pass in the log machinery.  This
currently only reduces code duplication, but should allow for other
simplifications and options to be used.

Finally, we hook a diff printer into the output chain.  Ideally we
would wire directly into the diff logic, to optionally use features
like word diff.  However, that will require some major reworking of
the diff chain, so we completely replace the output with our own diff
for now.

As this was a GSoC project, and has quite some history by now, many
people have helped.  In no particular order, thanks go to

  Jakub Narebski <jnareb@gmail.com>
  Jens Lehmann <Jens.Lehmann@web.de>
  Jonathan Nieder <jrnieder@gmail.com>
  Junio C Hamano <gitster@pobox.com>
  Ramsay Jones <ramsay@ramsay1.demon.co.uk>
  Will Palmer <wmpalmer@gmail.com>

Apologies to everyone I forgot.
Signed-off-by: NBo Yang <struggleyb.nku@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      12da1d1f
  19. 02 2月, 2013 1 次提交
  21. 11 1月, 2013 1 次提交
  23. 14 12月, 2012 1 次提交
  25. 07 9月, 2012 1 次提交
  27. 27 4月, 2012 1 次提交
    • J
      docs: stop using asciidoc no-inline-literal · 6cf378f0
      由 Jeff King 提交于 
      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: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6cf378f0
  29. 31 8月, 2011 1 次提交
  31. 05 8月, 2011 1 次提交
    • J
      docs: put listed example commands in backticks · 5d2fc913
      由 Jeff King 提交于 
      Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters.  Some manpages make a list of examples, like:

  git foo::
    Run git foo.

  git foo -q::
    Use the "-q" option.

to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).

This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).

As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5d2fc913
  33. 07 7月, 2011 1 次提交
    • M
      Documentation: use [verse] for SYNOPSIS sections · 7791a1d9
      由 Martin von Zweigbergk 提交于 
      The SYNOPSIS sections of most commands that span several lines already
use [verse] to retain line breaks. Most commands that don't span
several lines seem not to use [verse]. In the HTML output, [verse]
does not only preserve line breaks, but also makes the section
indented, which causes a slight inconsistency between commands that
use [verse] and those that don't. Use [verse] in all SYNOPSIS sections
for consistency.

Also remove the blank lines from git-fetch.txt and git-rebase.txt to
align with the other man pages. In the case of git-rebase.txt, which
already uses [verse], the blank line makes the [verse] not apply to
the last line, so removing the blank line also makes the formatting
within the document more consistent.

While at it, add single quotes to 'git cvsimport' for consistency with
other commands.
Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7791a1d9
  35. 31 3月, 2011 1 次提交
  37. 11 3月, 2011 1 次提交
    • J
      doc: drop author/documentation sections from most pages · 48bb914e
      由 Jeff King 提交于 
      The point of these sections is generally to:

  1. Give credit where it is due.

  2. Give the reader an idea of where to ask questions or
     file bug reports.

But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame.  For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody
useless.

So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.

Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.
      48bb914e
  39. 10 3月, 2011 1 次提交
  41. 09 3月, 2011 1 次提交
  43. 04 11月, 2010 1 次提交
  45. 14 10月, 2010 1 次提交
  47. 10 8月, 2010 1 次提交
  49. 09 7月, 2010 1 次提交
    • E
      Reorganize `git-log' man page to clarify common diff options. · 4ded6916
      由 Eli Barzilay 提交于 
      This will reduce considerably the common confusion where people miss the
`--follow' option, and wonder why `-M'/`-C' is not working.

* Move the diff options include to after the log-specific flags, and add
  a "Common diff options" subtitle before them.  (These options apply
  only when patches are shown, which is not a common use case among
  newbies, so having them first is confusing.)

* Move the `--follow' description to the top of the listed options.  The
  options before that seem less important: `--full-diff' applies only
  when patches are shown, `--source' and `--decorate' are less useful
  with many common commit specifications.

* Clarify that `--follow' works only for a single path argument.
Signed-off-by: NEli Barzilay <eli@barzilay.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4ded6916
  51. 06 7月, 2010 1 次提交
  53. 09 5月, 2010 1 次提交
  55. 08 5月, 2010 1 次提交
  57. 18 2月, 2010 1 次提交
    • J
      log.decorate: usability fixes · 8a3d203b
      由 Junio C Hamano 提交于 
      The configuration is meant to suppliment --decorate command line option
that can be used as a boolean to turn the feature on, so it is natural
to expect

	[log]
		decorate
		decorate = yes

to work.  The original commit would segfault with the first one, and
would not understand the second one.

Once a user has this configuration in ~/.gitconfig, there needs to be a
way to override it from the command line.  Add --no-decorate option to
log family and also allow --decorate=no to mean the same thing.  Since
we allow setting log.decorate to 'true', the command line also should
accept --decorate=yes and behave accordingly.

New tests in t4202 are designed to exercise the interaction between the
configuration variable and the command line option that overrides it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8a3d203b
  59. 13 2月, 2010 1 次提交
    • P
      git log -p -m: document -m and honor --first-parent · 88d9d45d
      由 Petr Baudis 提交于 
      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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      88d9d45d
  61. 21 1月, 2010 2 次提交