1. 29 8月, 2008 1 次提交
    • L
      Fix '--dirstat' with cross-directory renaming · 441bca0b
      Linus Torvalds 提交于
      The dirstat code depends on the fact that we always generate diffs with
      the names sorted, since it then just does a single-pass walk-over of the
      sorted list of names and how many changes there were. The sorting means
      that all files are nicely grouped by directory.
      
      That all works fine.
      
      Except when we have rename detection, and suddenly the nicely sorted list
      of pathnames isn't all that sorted at all. And now the single-pass dirstat
      walk gets all confused, and you can get results like this:
      
        [torvalds@nehalem linux]$ git diff --dirstat=2 -M v2.6.27-rc4..v2.6.27-rc5
           3.0% arch/powerpc/configs/
           6.8% arch/arm/configs/
           2.7% arch/powerpc/configs/
           4.2% arch/arm/configs/
           5.6% arch/powerpc/configs/
           8.4% arch/arm/configs/
           5.5% arch/powerpc/configs/
          23.3% arch/arm/configs/
           8.6% arch/powerpc/configs/
           4.0% arch/
           4.4% drivers/usb/musb/
           4.0% drivers/watchdog/
           7.6% drivers/
           3.5% fs/
      
      The trivial fix is to add a sorting pass, fixing it to:
      
        [torvalds@nehalem linux]$ git diff --dirstat=2 -M v2.6.27-rc4..v2.6.27-rc5
          43.0% arch/arm/configs/
          25.5% arch/powerpc/configs/
           5.3% arch/
           4.4% drivers/usb/musb/
           4.0% drivers/watchdog/
           7.6% drivers/
           3.5% fs/
      
      Spot the difference. In case anybody wonders: it's because of a ton of
      renames from {include/asm-blackfin => arch/blackfin/include/asm} that just
      totally messed up the file ordering in between arch/arm and arch/powerpc.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      441bca0b
  2. 21 8月, 2008 1 次提交
    • J
      diff --check: do not get confused by new blank lines in the middle · c35539eb
      Junio C Hamano 提交于
      The code remembered that the last diff output it saw was an empty line,
      and tried to reset that state whenever it sees a context line, a non-blank
      new line, or a new hunk.  However, this codepath asks the underlying diff
      engine to feed diff without any context, and the "just saw an empty line"
      state was not reset if you added a new blank line in the last hunk of your
      patch, even if it is not the last line of the file.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c35539eb
  3. 13 8月, 2008 1 次提交
  4. 12 8月, 2008 1 次提交
  5. 06 8月, 2008 1 次提交
    • L
      diff.renamelimit is a basic diff configuration · 2b6ca6df
      Linus Torvalds 提交于
      The configuration was added as a core option in 3299c6f6 (diff: make
      default rename detection limit configurable., 2005-11-15), but 9ce392f4
      (Move diff.renamelimit out of default configuration., 2005-11-21)
      separated diff-related stuff out of the core.
      
      Up to that point it was Ok.
      
      When we separated the Porcelain options out of the git_diff_config in
      83ad63cf (diff: do not use configuration magic at the core-level,
      2006-07-08), we should have been more careful.
      
      This mistake made diff-tree plumbing and git-show Porcelain to notice
      different set of renames when the user explicitly asked for rename
      detection.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2b6ca6df
  6. 03 8月, 2008 3 次提交
  7. 30 7月, 2008 1 次提交
    • K
      format-patch: Produce better output with --inline or --attach · 6b2fbaaf
      Kevin Ballard 提交于
      This patch makes two small changes to improve the output of --inline
      and --attach.
      
      The first is to write a newline preceding the boundary. This is needed because
      MIME defines the encapsulation boundary as including the preceding CRLF (or in
      this case, just LF), so we should be writing one. Without this, the last
      newline in the pre-diff content is consumed instead.
      
      The second change is to always write the line termination character
      (default: newline) even when using --inline or --attach. This is simply to
      improve the aesthetics of the resulting message. When using --inline an email
      client should render the resulting message identically to the non-inline
      version. And when using --attach this adds a blank line preceding the
      attachment in the email, which is visually attractive.
      Signed-off-by: NKevin Ballard <kevin@sb.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6b2fbaaf
  8. 17 7月, 2008 1 次提交
  9. 06 7月, 2008 1 次提交
  10. 29 6月, 2008 1 次提交
  11. 27 6月, 2008 6 次提交
  12. 17 6月, 2008 2 次提交
    • J
      4afbcab9
    • S
      diff: reset color before printing newline · 06ff64ae
      SZEDER Gábor 提交于
      It worked that way since commit 50f575fc (Tweak diff colors,
      2006-06-22), but commit c1795bb0 (Unify whitespace checking, 2007-12-13)
      changed it.  This patch restores the old behaviour.
      
      Besides Linus' arguments in the log message of 50f575fc, resetting color
      before printing newline is also important to keep 'git add --patch'
      happy.  If the last line(s) of a file are removed, then that hunk will
      end with a colored line.  However, if the newline comes before the color
      reset, then the diff output will have an additional line at the end
      containing only the reset sequence.  This causes trouble in
      git-add--interactive.perl's parse_diff function, because @colored will
      have one more element than @diff, and that last element will contain the
      color reset.  The elements of these arrays will then be copied to @hunk,
      but only as many as the number of elements in @diff.  As a result the
      last color reset is lost and all subsequent terminal output will be
      printed in color.
      Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      06ff64ae
  13. 15 6月, 2008 1 次提交
    • J
      avoid trailing whitespace in zero-change diffstat lines · 4d9b5359
      Jeff King 提交于
      In some cases, we produce a diffstat line even though no
      lines have changed (e.g., because of an exact rename). In
      this case, there is no +/- "graph" after the number of
      changed lines. However, we output the space separator
      unconditionally, meaning that these lines contained a
      trailing space character.
      
      This isn't a huge problem, but in cleaning up the output we
      are able to eliminate some trailing whitespace from a test
      vector.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4d9b5359
  14. 16 5月, 2008 1 次提交
  15. 15 5月, 2008 1 次提交
  16. 04 5月, 2008 2 次提交
  17. 09 4月, 2008 1 次提交
  18. 14 3月, 2008 1 次提交
  19. 02 3月, 2008 2 次提交
    • J
      diff: make sure work tree side is shown as 0{40} when different · 2b459b48
      Junio C Hamano 提交于
      Ping Yin noticed that "git diff-index --raw" shows 0{40} when work tree
      has submodule difference, but "git diff --raw" didn't correctly do so.
      
      There was a mistake in the diffcore_skip_stat_unmatch() that was meant to
      clean up the stat-only difference for running diff between the index and
      work tree and diff between the tree and the work tree, to cause it re-read
      from the submodule repository HEAD.  When ce_stat_match() says work tree
      is different, we should always say 0{40} on the work tree side.
      
      This patch fixes the issue, and adds tests.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2b459b48
    • J
      Clean up find_unique_abbrev() callers · 2efb3b06
      Junio C Hamano 提交于
      Now find_unique_abbrev() never returns NULL, there is no need for callers
      to prepare for seeing NULL and fall back to giving the full 40-hexdigits.
      
      While we are at it, drop "..." in the "git reset" output that reports the
      location of the new HEAD, between the abbreviated commit object name and
      the one line commit summary.  Because we are always showing the HEAD
      (which cannot be missing!), we never had a case where we show the full 40
      hexdigits that is not followed by three dots, and these three dots were
      stealing 3 columns from the precious horizontal screen real estate out of
      80 that can better be used for the one line commit summary.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2efb3b06
  20. 26 2月, 2008 1 次提交
  21. 25 2月, 2008 1 次提交
  22. 23 2月, 2008 1 次提交
    • J
      Avoid unnecessary "if-before-free" tests. · 8e0f7003
      Jim Meyering 提交于
      This change removes all obvious useless if-before-free tests.
      E.g., it replaces code like this:
      
              if (some_expression)
                      free (some_expression);
      
      with the now-equivalent:
      
              free (some_expression);
      
      It is equivalent not just because POSIX has required free(NULL)
      to work for a long time, but simply because it has worked for
      so long that no reasonable porting target fails the test.
      Here's some evidence from nearly 1.5 years ago:
      
          http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
      
      FYI, the change below was prepared by running the following:
      
        git ls-files -z | xargs -0 \
        perl -0x3b -pi -e \
          's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
      
      Note however, that it doesn't handle brace-enclosed blocks like
      "if (x) { free (x); }".  But that's ok, since there were none like
      that in git sources.
      
      Beware: if you do use the above snippet, note that it can
      produce syntactically invalid C code.  That happens when the
      affected "if"-statement has a matching "else".
      E.g., it would transform this
      
        if (x)
          free (x);
        else
          foo ();
      
      into this:
      
        free (x);
        else
          foo ();
      
      There were none of those here, either.
      
      If you're interested in automating detection of the useless
      tests, you might like the useless-if-before-free script in gnulib:
      [it *does* detect brace-enclosed free statements, and has a --name=S
       option to make it detect free-like functions with different names]
      
        http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
      
      Addendum:
        Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
      Signed-off-by: NJim Meyering <meyering@redhat.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8e0f7003
  23. 21 2月, 2008 1 次提交
  24. 18 2月, 2008 1 次提交
  25. 16 2月, 2008 5 次提交
  26. 14 2月, 2008 1 次提交