Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 20 3月, 2015 1 次提交
  3. 14 1月, 2015 1 次提交
    • C
      log: teach --invert-grep option · 22dfa8a2
      由 Christoph Junghans 提交于 
      "git log --grep=<string>" shows only commits with messages that
match the given string, but sometimes it is useful to be able to
show only commits that do *not* have certain messages (e.g. "show
me ones that are not FIXUP commits").

Originally, we had the invert-grep flag in grep_opt, but because
"git grep --invert-grep" does not make sense except in conjunction
with "--files-with-matches", which is already covered by
"--files-without-matches", it was moved it to revisions structure.
To have the flag there expresses the function to the feature better.

When the newly inserted two tests run, the history would have commits
with messages "initial", "second", "third", "fourth", "fifth", "sixth"
and "Second", committed in this order.  The commits that does not match
either "th" or "Sec" is "second" and "initial". For the case insensitive
case only "initial" matches.
Signed-off-by: NChristoph Junghans <ottxor@gentoo.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      22dfa8a2
  5. 10 7月, 2014 1 次提交
    • Z
      log: fix indentation for --graph --show-signature · cf3983d1
      由 Zoltan Klinger 提交于 
      The git log --graph --show-signature command incorrectly indents the gpg
information about signed commits and merged signed tags. It does not
follow the level of indentation of the current commit.

Example of garbled output:
$ git log --show-signature --graph
*   commit 258e0a237cb69aaa587b0a4fb528bb0316b1b776
|\  gpg: Signature made Mon, Jun 30, 2014 13:22:33 EDT using RSA key ID DA08
gpg: Good signature from "Jason Pyeron <jpye...@pdinc.us>"
Merge: 727c355 1ca13ed
| | Author: Jason Pyeron <jpye...@pdinc.us>
| | Date:   Mon Jun 30 13:22:29 2014 -0400
| |
| |     Merge of 1ca13ed2271d60ba9 branch - rebranding
| |
| * commit 1ca13ed2271d60ba93d40bcc8db17ced8545f172
| | gpg: Signature made Mon, Jun 23, 2014  9:45:47 EDT using RSA key ID DD37
gpg: Good signature from "Stephen Robert Guglielmo <s...@guglielmo.us>"
gpg:                 aka "Stephen Robert Guglielmo <srguglie...@gmail.com>"
Author: Stephen R Guglielmo <s...@guglielmo.us>
| | Date:   Mon Jun 23 09:45:27 2014 -0400
| |
| |     Minor URL updates

In log-tree.c modify show_sig_lines() function to call graph_show_oneline()
after each line of gpg information it has printed in order to preserve
the level of indentation for the next output line.
Reported-by: NJason Pyeron <jpyeron@pdinc.us>
Signed-off-by: NZoltan Klinger <zoltan.klinger@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cf3983d1
  7. 29 5月, 2013 1 次提交
    • C
      fix segfault with git log -c --follow · 46ec510a
      由 Clemens Buchacher 提交于 
      In diff_tree_combined we make a copy of diffopts. In
try_to_follow_renames, called via diff_tree_sha1, we free and
re-initialize diffopts->pathspec->items. Since we did not make a deep
copy of diffopts in diff_tree_combined, the original diffopts does not
get the update. By the time we return from diff_tree_combined,
rev->diffopt->pathspec->items points to an invalid memory address. We
get a segfault next time we try to access that pathspec.

Instead, along with the copy of diffopts, make a copy pathspec->items as
well.

We would also have to make a copy of pathspec->raw to keep it consistent
with pathspec->items, but nobody seems to rely on that.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      46ec510a
  9. 25 3月, 2013 1 次提交
  11. 19 10月, 2012 1 次提交
    • J
      utf8: fix off-by-one wrapping of text · 14e1a4e1
      由 Jan H. Schönherr 提交于 
      The wrapping logic in strbuf_add_wrapped_text() does currently not allow
lines that entirely fill the allowed width, instead it wraps the line one
character too early.

For example, the text "This is the sixth commit." formatted via
"%w(11,1,2)" (wrap at 11 characters, 1 char indent of first line, 2 char
indent of following lines) results in four lines: " This is", "  the",
"  sixth", "  commit." This is wrong, because "  the sixth" is exactly
11 characters long, and thus allowed.

Fix this by allowing the (width+1) character of a line to be a valid
wrapping point if it is a whitespace character.
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      14e1a4e1
  13. 10 10月, 2012 1 次提交
  15. 26 9月, 2012 1 次提交
  17. 31 8月, 2012 1 次提交
    • M
      teach log --no-walk=unsorted, which avoids sorting · ca92e59e
      由 Martin von Zweigbergk 提交于 
      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 (8e64006e (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: NMartin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ca92e59e
  19. 28 8月, 2012 1 次提交
  21. 24 8月, 2012 1 次提交
    • J
      specifying ranges: we did not mean to make ".." an empty set · 003c84f6
      由 Junio C Hamano 提交于 
      Either end of revision range operator can be omitted to default to HEAD,
as in "origin.." (what did I do since I forked) or "..origin" (what did
they do since I forked).  But the current parser interprets ".."  as an
empty range "HEAD..HEAD", and worse yet, because ".." does exist on the
filesystem, we get this annoying output:

  $ cd Documentation/howto
  $ git log .. ;# give me recent commits that touch Documentation/ area.
  fatal: ambiguous argument '..': both revision and filename
  Use '--' to separate filenames from revisions

Surely we could say "git log ../" or even "git log -- .." to disambiguate,
but we shouldn't have to.
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      003c84f6
  23. 01 5月, 2012 1 次提交
    • Z
      diff --stat: use less columns for change counts · dc801e71
      由 Zbigniew Jędrzejewski-Szmek 提交于 
      Number of columns required for change counts is now computed based on
the maximum number of changed lines instead of being fixed. This means
that usually a few more columns will be available for the filenames
and the graph.

The graph width logic is also modified to include enough space for
"Bin XXX -> YYY bytes".

If changes to binary files are mixed with changes to text files,
change counts are padded to take at least three columns. And the other
way around, if change counts require more than three columns, then
"Bin"s are padded to align with the change count. This way, the +-
part starts in the same column as "XXX -> YYY" part for binary files.
This makes the graph easier to parse visually thanks to the empty
column. This mimics the layout of diff --stat before this change.

Tests and the tutorial are updated to reflect the new --stat output.
This means either the removal of extra padding and/or the addition of
up to three extra characters to truncated filenames. One test is added
to check the graph alignment when a binary file change and text file
change of more than 999 lines are committed together.
Signed-off-by: NZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dc801e71
  25. 21 3月, 2012 1 次提交
  27. 08 11月, 2011 1 次提交
  29. 19 5月, 2011 1 次提交
  31. 18 11月, 2010 1 次提交
    • J
      log.decorate: accept 0/1 bool values · b2be2f6a
      由 Jeff King 提交于 
      We explicitly document "0" and "1" as synonyms for "false"
and "true" in boolean config options. However, we don't
actually handle those values in git_config_maybe_bool.

In most cases this works fine, as we call git_config_bool,
which in turn calls git_config_bool_or_int, which in turn
calls git_config_maybe_bool. Values of 0/1 are considered
"not bool", but their integer values end up being converted
to the corresponding boolean values.

However, the log.decorate code looks for maybe_bool
explicitly, so that it can fall back to the "short" and
"full" strings. It does not handle 0/1 at all, and considers
them invalid values.

We cannot simply add 0/1 support to git_config_maybe_bool.
That would confuse git_config_bool_or_int, which may want to
distinguish the integer values "0" and "1" from bools.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b2be2f6a
  33. 10 11月, 2010 1 次提交
  35. 07 10月, 2010 1 次提交
  37. 16 8月, 2010 1 次提交
  39. 07 8月, 2010 2 次提交
  41. 09 4月, 2010 1 次提交
    • J
      log.decorate: only ignore it under "log --pretty=raw" · 4f62c2bc
      由 Junio C Hamano 提交于 
      Unlike notes that are often multi-line and disrupting to be placed in many
output formats, a decoration is designed to be a small token that can be
tacked after an existing line of the output where a commit object name sits.
Disabling log.decorate for something like "log --oneline" would defeat the
purpose of the configuration.

We _might_ want to change it further in the future to force scripts that
do not want to be broken by random end user configurations to explicitly
say "log --no-decorate", but that would be an incompatible change that
needs the usual multi-release-cycle deprecation process.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4f62c2bc
  43. 07 4月, 2010 1 次提交
    • J
      log --pretty/--oneline: ignore log.decorate · 635530a2
      由 Junio C Hamano 提交于 
      Many scripts, most notably gitk, rely on output from the log family of
command not to be molested by random user configuration.  This is
especially true when --pretty=raw is given.

Just like we disable notes output unless the command line explicitly
asks for --show-notes, disable the decoration code unless --decorate is
given explicitly from the command line and --pretty or --oneline is
given.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      635530a2
  45. 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
  47. 27 1月, 2010 1 次提交
  49. 23 11月, 2009 1 次提交
  51. 10 8月, 2009 1 次提交
    • J
      merge: fix incorrect merge message for ambiguous tag/branch · 751c5974
      由 Jeff King 提交于 
      If we have both a tag and a branch named "foo", then calling
"git merge foo" will warn about the ambiguous ref, but merge
the tag.

When generating the commit message, though, we simply
checked whether "refs/heads/foo" existed, and if it did,
assumed it was a branch. This led to the statement "Merge
branch 'foo'" in the commit message, which is quite wrong.

Instead, we should use dwim_ref to find the actual ref used,
and describe it appropriately.

In addition to the test in t7608, we must also tweak the
expected output of t4202, which was accidentally triggering
this bug.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      751c5974
  53. 19 7月, 2009 1 次提交
  55. 27 4月, 2009 1 次提交
  57. 23 4月, 2009 3 次提交
  59. 25 2月, 2009 1 次提交
  61. 20 2月, 2009 1 次提交
  63. 24 1月, 2009 1 次提交
  65. 25 8月, 2008 1 次提交
    • J
      Fix "git log -i --grep" · 0843acfd
      由 Jeff King 提交于 
      This has been broken in v1.6.0 due to the reorganization of
the revision option parsing code. The "-i" is completely
ignored, but works fine in "git log --grep -i".

What happens is that the code for "-i" looks for
revs->grep_filter; if it is NULL, we do nothing, since there
are no grep filters. But that is obviously not correct,
since we want it to influence the later --grep option. Doing
it the other way around works, since "-i" just impacts the
existing grep_filter option.

Instead, we now always initialize the grep_filter member and
just fill in options and patterns as we get them. This means
that we can no longer check grep_filter for NULL, but
instead must check the pattern list to see if we have any
actual patterns.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0843acfd
  67. 02 8月, 2008 1 次提交
  69. 24 7月, 2008 1 次提交
  71. 27 12月, 2007 1 次提交