Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 30 11月, 2012 1 次提交
    • J
      t4049: refocus tests · de909595
      由 Junio C Hamano 提交于 
      The primary thing Linus's patch wanted to change was to make sure
that 0-line change appears for a mode-only change.  Update the
first test to chmod a file that we can see in the output (limited
by --stat-count) to demonstrate it.  Also make sure to use test_chmod
and compare the index and the tree, so that we can run this test
even on a filesystem without permission bits.

Later two tests are about fixes to separate issues that were
introduced and/or uncovered by Linus's patch as a side effect, but
the issues are not related to mode-only changes.  Remove chmod from
the tests.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      de909595
  3. 28 11月, 2012 6 次提交
    • 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
    • J
      test: add failing tests for "diff --stat" to t4049 · 9667ccbc
      由 Junio C Hamano 提交于 
      There are a few problems in diff.c around --stat area, partially
caused by the recent 74faaa16 (Fix "git diff --stat" for interesting
- but empty - file changes, 2012-10-17), and largely caused by the
earlier change that introduced when --stat-count was added.

Add a few test pieces to t4049 to expose the issues.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9667ccbc
  5. 18 10月, 2012 16 次提交
  7. 17 10月, 2012 6 次提交
  9. 16 10月, 2012 3 次提交
  11. 15 10月, 2012 1 次提交
  13. 14 10月, 2012 2 次提交
  15. 13 10月, 2012 2 次提交
    • J
      Merge branch 'maint' · fc364c76
      由 Junio C Hamano 提交于 
      * maint:
  gitweb.cgi: fix "comitter_tz" typo in feed
      fc364c76
    • J
      http: fix segfault in handle_curl_result · 188923f0
      由 Jeff King 提交于 
      When we create an http active_request_slot, we can set its
"results" pointer back to local storage. The http code will
fill in the details of how the request went, and we can
access those details even after the slot has been cleaned
up.

Commit 88097030 (http: factor out http error code handling)
switched us from accessing our local results struct directly
to accessing it via the "results" pointer of the slot. That
means we're accessing the slot after it has been marked as
finished, defeating the whole purpose of keeping the results
storage separate.

Most of the time this doesn't matter, as finishing the slot
does not actually clean up the pointer. However, when using
curl's multi interface with the dumb-http revision walker,
we might actually start a new request before handing control
back to the original caller. In that case, we may reuse the
slot, zeroing its results pointer, and leading the original
caller to segfault while looking for its results inside the
slot.

Instead, we need to pass a pointer to our local results
storage to the handle_curl_result function, rather than
relying on the pointer in the slot struct. This matches what
the original code did before the refactoring (which did not
use a separate function, and therefore just accessed the
results struct directly).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      188923f0
  17. 12 10月, 2012 2 次提交
  19. 11 10月, 2012 1 次提交