Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 18 7月, 2013 1 次提交
    • J
      diff: pass the whole diff_options to diffcore_apply_filter() · 949226fe
      由 Junio C Hamano 提交于 
      The --diff-filter=<arg> option given by the user is kept as a
string, and passed to the underlying diffcore_apply_filter()
function as a string for each resulting path we run number of
strchr() to see if each class of change among ACDMRTXUB is meant to
be given.

Change the function signature to pass the whole diff_options, so
that we can pre-parse this string in the next patch.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      949226fe
  3. 13 4月, 2013 1 次提交
  5. 06 4月, 2013 1 次提交
  7. 22 3月, 2013 1 次提交
  9. 27 2月, 2013 1 次提交
  11. 24 2月, 2013 1 次提交
    • A
      diff: Fix rename pretty-print when suffix and prefix overlap · d020e27f
      由 Antoine Pelisse 提交于 
      When considering a rename for two files that have a suffix and a prefix
that can overlap, a confusing line is shown. As an example, renaming
"a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".

Currently, what we do is calculate the common prefix ("a/b/"), and the
common suffix ("/b/c"), but the same "/b/" is actually counted both in
prefix and suffix. Then when calculating the size of the non-common part,
we end-up with a negative value which is reset to 0, thus the "{ => }".

Do not allow the common suffix to overlap the common prefix and stop
when reaching a "/" that would be in both.
Signed-off-by: NAntoine Pelisse <apelisse@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d020e27f
  13. 13 2月, 2013 4 次提交
  15. 17 1月, 2013 2 次提交
  17. 28 11月, 2012 5 次提交
    • J
      diff --shortstat: do not count "unmerged" entries · 20c8cde4
      由 Junio C Hamano 提交于 
      Fix the same issue as the previous one for "git diff --stat";
unmerged entries was doubly-counted.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      20c8cde4
    • J
      diff --stat: do not count "unmerged" entries · 82dfc2c4
      由 Junio C Hamano 提交于 
      Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.

The separation done by the previous step makes this fix simple and
straightforward.  Among the filepairs in diff_queue, paths that
weren't modified, and the extra "unmerged" entries do not count as
total number of files.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      82dfc2c4
    • J
      diff --stat: move the "total count" logic to the last loop · a20d3c0d
      由 Junio C Hamano 提交于 
      The diffstat generation logic, with --stat-count limit, is
implemented as three loops.

 - The first counts the width necessary to show stats up to
   specified number of entries, and notes up to how many entries in
   the data we need to iterate to show the graph;

 - The second iterates that many times to draw the graph, adjusts
   the number of "total modified files", and counts the total
   added/deleted lines for the part that was shown in the graph;

 - The third iterates over the remainder and only does the part to
   count "total added/deleted lines" and to adjust "total modified
   files" without drawing anything.

Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.

This incidentally fixes a bug.  The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should.  The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a20d3c0d
    • J
      diff --stat: use "file" temporary variable to refer to data->files[i] · af0ed819
      由 Junio C Hamano 提交于 
      The generated code shouldn't change but it is easier to read.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      af0ed819
    • J
      diff --stat: status of unmodified pair in diff-q is not zero · 99bfd407
      由 Junio C Hamano 提交于 
      It is spelled DIFF_STATUS_UNKNOWN these days, and is different from zero.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      99bfd407
  19. 19 11月, 2012 3 次提交
  21. 29 10月, 2012 2 次提交
    • N
      Move setup_diff_pager to libgit.a · 4914c962
      由 Nguyễn Thái Ngọc Duy 提交于 
      This is used by diff-no-index.c, part of libgit.a while it stays in
builtin/diff.c. Move it to diff.c so that we won't get undefined
reference if a program that uses libgit.a happens to pull it in.

While at it, move check_pager from git.c to pager.c. It makes more
sense there and pager.c is also part of libgit.a
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJeff King <peff@peff.net>
      4914c962
    • M
      parse_dirstat_params(): use string_list to split comma-separated string · 02e8ca0e
      由 Michael Haggerty 提交于 
      Use string_list_split_in_place() to split the comma-separated
parameters string.  This simplifies the code and also fixes a bug: the
old code made calls like

    memcmp(p, "lines", p_len)

which needn't work if p_len is different than the length of the
constant string (and could illegally access memory if p_len is larger
than the length of the constant string).

When p_len was less than the length of the constant string, the old
code would have allowed some abbreviations to be accepted (e.g., "cha"
for "changes") but this seems to have been a bug rather than a
feature, because (1) it is not documented; (2) no attempt was made to
handle ambiguous abbreviations, like "c" for "changes" vs
"cumulative".
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJeff King <peff@peff.net>
      02e8ca0e
  23. 18 10月, 2012 1 次提交
    • L
      Fix "git diff --stat" for interesting - but empty - file changes · 74faaa16
      由 Linus Torvalds 提交于 
      The behavior of "git diff --stat" is rather odd for files that have
zero lines of changes: it will discount them entirely unless they were
renames.

Which means that the stat output will simply not show files that only
had "other" changes: they were created or deleted, or their mode was
changed.

Now, those changes do show up in the summary, but so do renames, so
the diffstat logic is inconsistent. Why does it show renames with zero
lines changed, but not mode changes or added files with zero lines
changed?

So change the logic to not check for "is_renamed", but for
"is_interesting" instead, where "interesting" is judged to be any
action but a pure data change (because a pure data change with zero
data changed really isn't worth showing, if we ever get one in our
diffpairs).

So if you did

   chmod +x Makefile
   git diff --stat

before, it would show empty (" 0 files changed"), with this it shows

 Makefile | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

which I think is a more correct diffstat (and then with "--summary" it
shows *what* the metadata change to Makefile was - this is completely
consistent with our handling of renamed files).

Side note: the old behavior was *really* odd. With no changes at all,
"git diff --stat" output was empty. With just a chmod, it said "0
files changed". No way is our legacy behavior sane.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      74faaa16
  25. 01 10月, 2012 1 次提交
  27. 22 9月, 2012 1 次提交
    • J
      diff: accept --no-follow option · aebbcf57
      由 Junio C Hamano 提交于 
      Once you do

	$ alias glogone git log --follow

there is no way to say

	$ glogone --no-follow ...

Not that "log --follow" is all that useful, but it is cheap to
support the common "you can defeat an undesirable option with a
'no-' variant of it later on the command line" pattern.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      aebbcf57
  29. 16 9月, 2012 1 次提交
  31. 15 9月, 2012 1 次提交
  33. 06 8月, 2012 1 次提交
    • A
      Fix '\ No newline...' annotation in rewrite diffs · 35e2d03c
      由 Adam Butcher 提交于 
      When a file that ends with an incomplete line is expressed as a
complete rewrite with the -B option, git diff incorrectly
appends the incomplete line indicator "\ No newline at end of
file" after such a line, rather than writing it on a line of its
own (the output codepath for normal output without -B does not
have this problem).  Add a LF after the incomplete line before
writing the "\ No newline ..." out to fix this.

Add a couple of tests to confirm that the indicator comment is
generated on its own line in both plain diff and rewrite mode.
Signed-off-by: NAdam Butcher <dev.lists@jessamine.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      35e2d03c
  35. 04 8月, 2012 1 次提交
    • T
      diff_setup_done(): return void · 28452655
      由 Thomas Rast 提交于 
      diff_setup_done() has historically returned an error code, but lost
the last nonzero return in 943d5b73 (allow diff.renamelimit to be set
regardless of -M/-C, 2006-08-09).  The callers were in a pretty
confused state: some actually checked for the return code, and some
did not.

Let it return void, and patch all callers to take this into account.
This conveniently also gets rid of a handful of different(!) error
messages that could never be triggered anyway.

Note that the function can still die().
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      28452655
  37. 30 7月, 2012 1 次提交
    • J
      diff: do not use null sha1 as a sentinel value · e5450100
      由 Jeff King 提交于 
      The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).

The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.

We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.

This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.

One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e5450100
  39. 27 7月, 2012 1 次提交
  41. 18 7月, 2012 1 次提交
    • J
      diff: correctly disable external_diff with --no-ext-diff · bd8c1a9b
      由 Junio C Hamano 提交于 
      Upon seeing a type-change filepair, "diff --no-ext-diff" does not
show the usual "deletion followed by addition" split patch and does
not run the external diff driver either.

This is because the logic to disable external diff was placed at a
wrong level in the callchain.  run_diff_cmd() decides to show the
split patch only when external diff driver is not configured or
specified via GIT_EXTERNAL_DIFF environment, but this is done before
checking if --no-ext-diff was given.  To make things worse,
run_diff_cmd() checks --no-ext-diff and disables the output for such
a filepair completely, as the callchain below it (e.g. builtin_diff)
does not want to handle typechange filepairs.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bd8c1a9b
  43. 29 6月, 2012 1 次提交
    • J
      diff-index.c: "git diff" has no need to read blob from the standard input · 4682d852
      由 Junio C Hamano 提交于 
      Only "diff --no-index -" does.  Bolting the logic into the low-level
function diff_populate_filespec() was a layering violation from day
one.  Move populate_from_stdin() function out of the generic diff.c
to its only user, diff-index.c.

Also make sure "-" from the command line stays a special token "read
from the standard input", even if we later decide to sanitize the
result from prefix_filename() function in a few obvious ways,
e.g. removing unnecessary "./" prefix, duplicated slashes "//" in
the middle, etc.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4682d852
  45. 16 6月, 2012 1 次提交
  47. 02 5月, 2012 2 次提交
  49. 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
  51. 19 4月, 2012 1 次提交
  53. 17 4月, 2012 1 次提交
  55. 24 3月, 2012 1 次提交
    • J
      teach diffcore-rename to optionally ignore empty content · 90d43b07
      由 Jeff King 提交于 
      Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.

However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).

This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.

One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).

A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      90d43b07