1. 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
  2. 16 5月, 2008 1 次提交
  3. 15 5月, 2008 1 次提交
  4. 04 5月, 2008 2 次提交
  5. 09 4月, 2008 1 次提交
  6. 14 3月, 2008 1 次提交
  7. 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
  8. 26 2月, 2008 1 次提交
  9. 25 2月, 2008 1 次提交
  10. 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
  11. 21 2月, 2008 1 次提交
  12. 18 2月, 2008 1 次提交
  13. 16 2月, 2008 5 次提交
  14. 14 2月, 2008 2 次提交
    • J
      diff --relative: help working in a bare repository · c0cb4a06
      Junio C Hamano 提交于
      This allows the --relative option to say which subdirectory to
      pretend to be in, so that in a bare repository, you can say:
      
          $ git log --relative=drivers/ v2.6.20..v2.6.22 -- drivers/scsi/
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c0cb4a06
    • J
      diff --relative: output paths as relative to the current subdirectory · cd676a51
      Junio C Hamano 提交于
      This adds --relative option to the diff family.  When you start
      from a subdirectory:
      
              $ git diff --relative
      
      shows only the diff that is inside your current subdirectory,
      and without $prefix part.  People who usually live in
      subdirectories may like it.
      
      There are a few things I should also mention about the change:
      
       - This works not just with diff but also works with the log
         family of commands, but the history pruning is not affected.
      
         In other words, if you go to a subdirectory, you can say:
      
              $ git log --relative -p
      
         but it will show the log message even for commits that do not
         touch the current directory.  You can limit it by giving
         pathspec yourself:
      
              $ git log --relative -p .
      
         This originally was not a conscious design choice, but we
         have a way to affect diff pathspec and pruning pathspec
         independently.  IOW "git log --full-diff -p ." tells it to
         prune history to commits that affect the current subdirectory
         but show the changes with full context.  I think it makes
         more sense to leave pruning independent from --relative than
         the obvious alternative of always pruning with the current
         subdirectory, which would break the symmetry.
      
       - Because this works also with the log family, you could
         format-patch a single change, limiting the effect to your
         subdirectory, like so:
      
              $ cd gitk-git
              $ git format-patch -1 --relative 911f1eb
      
         But because that is a special purpose usage, this option will
         never become the default, with or without repository or user
         preference configuration.  The risk of producing a partial
         patch and sending it out by mistake is too great if we did
         so.
      
       - This is inherently incompatible with --no-index, which is a
         bolted-on hack that does not have much to do with git
         itself.  I didn't bother checking and erroring out on the
         combined use of the options, but probably I should.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cd676a51
  15. 13 2月, 2008 1 次提交
    • L
      Add "--dirstat" for some directory statistics · 7df7c019
      Linus Torvalds 提交于
      This adds a new form of overview diffstat output, doing something that I
      have occasionally ended up doing manually (and badly, because it's
      actually pretty nasty to do), and that I think is very useful for an
      project like the kernel that has a fairly deep and well-separated
      directory structure with semantic meaning.
      
      What I mean by that is that it's often interesting to see exactly which
      sub-directories are impacted by a patch, and to what degree - even if you
      don't perhaps care so much about the individual files themselves.
      
      What makes the concept more interesting is that the "impact" is often
      hierarchical: in the kernel, for example, something could either have a
      very localized impact to "fs/ext3/" and then it's interesting to see that
      such a patch changes mostly that subdirectory, but you could have another
      patch that changes some generic VFS-layer issue which affects _many_
      subdirectories that are all under "fs/", but none - or perhaps just a
      couple of them - of the individual filesystems are interesting in
      themselves.
      
      So what commonly happens is that you may have big changes in a specific
      sub-subdirectory, but still also significant separate changes to the
      subdirectory leading up to that - maybe you have significant VFS-level
      changes, but *also* changes under that VFS layer in the NFS-specific
      directories, for example. In that case, you do want the low-level parts
      that are significant to show up, but then the insignificant ones should
      show up as under the more generic top-level directory.
      
      This patch shows all of that with "--dirstat". The output can be either
      something simple like
      
              commit 81772fe...
              Author: Thomas Gleixner <tglx@linutronix.de>
              Date:   Sun Feb 10 23:57:36 2008 +0100
      
                  x86: remove over noisy debug printk
      
                  pageattr-test.c contains a noisy debug printk that people reported.
                  The condition under which it prints (randomly tapping into a mem_map[]
                  hole and not being able to c_p_a() there) is valid behavior and not
                  interesting to report.
      
                  Remove it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      
               100.0% arch/x86/mm/
      
      or something much more complex like
      
              commit e231c2e...
              Author: David Howells <dhowells@redhat.com>
              Date:   Thu Feb 7 00:15:26 2008 -0800
      
                  Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
      
      	  20.5% crypto/
      	   7.6% fs/afs/
      	   7.6% fs/fuse/
      	   7.6% fs/gfs2/
      	   5.1% fs/jffs2/
      	   5.1% fs/nfs/
      	   5.1% fs/nfsd/
      	   7.6% fs/reiserfs/
      	  15.3% fs/
      	   7.6% net/rxrpc/
      	  10.2% security/keys/
      
      where that latter example is an example of significant work in some
      individual fs/*/ subdirectories (like the patches to reiserfs accounting
      for 7.6% of the whole), but then discounting those individual filesystems,
      there's also 15.3% other "random" things that weren't worth reporting on
      their oen left over under fs/ in general (either in that directory itself,
      or in subdirectories of fs/ that didn't have enough changes to be reported
      individually).
      
      I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
      is under fs/ but that was _not_ significant enough to report on its own.
      So the above does _not_ mean that 15.3% of the work was under fs/ per se,
      because that 15.3% does *not* include the already-reported 7.6% of afs,
      7.6% of fuse etc.
      
      If you want to enable "cumulative" directory statistics, you can use the
      "--cumulative" flag, which adds up percentages recursively even when
      they have been already reported for a sub-directory.  That cumulative
      output is disabled if *all* of the changes in one subdirectory come from
      a deeper subdirectory, to avoid repeating subdirectories all the way to
      the root.
      
      For an example of the cumulative reporting, the above commit becomes
      
      	commit e231c2e...
      	Author: David Howells <dhowells@redhat.com>
      	Date:   Thu Feb 7 00:15:26 2008 -0800
      
      	    Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
      
      	  20.5% crypto/
      	   7.6% fs/afs/
      	   7.6% fs/fuse/
      	   7.6% fs/gfs2/
      	   5.1% fs/jffs2/
      	   5.1% fs/nfs/
      	   5.1% fs/nfsd/
      	   7.6% fs/reiserfs/
      	  61.5% fs/
      	   7.6% net/rxrpc/
      	  10.2% security/keys/
      
      in which the commit percentages now obviously add up to much more than
      100%: now the changes that were already reported for the sub-directories
      under fs/ are then cumulatively included in the whole percentage of fs/
      (ie now shows 61.5% as opposed to the 15.3% without the cumulative
      reporting).
      
      The default reporting limit has been arbitrarily set at 3%, which seems
      to be a pretty good cut-off, but you can specify the cut-off manually by
      giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
      at 5% instead)
      
      NOTE! The percentages are purely about the total lines added and removed,
      not anything smarter (or dumber) than that. Also note that you should not
      generally expect things to add up to 100%: not only does it round down, we
      don't report leftover scraps (they add up to the top-level change count,
      but we don't even bother reporting that, it only reports subdirectories).
      
      Quite frankly, as a top-level manager this is really convenient for me,
      but it's going to be very boring for git itself since there are few
      subdirectories. Also, don't expect things to make tons of sense if you
      combine this with "-M" and there are cross-directory renames etc.
      
      But even for git itself, you can get some fun statistics. Try out
      
              git log --dirstat
      
      and see the occasional mentions of things like Documentation/, git-gui/,
      gitweb/ and gitk-git/. Or try out something like
      
              git diff --dirstat v1.5.0..v1.5.4
      
      which does kind of git an overview that shows *something*. But in general,
      the output is more exciting for big projects with deeper structure, and
      doing a
      
              git diff --dirstat v2.6.24..v2.6.25-rc1
      
      on the kernel is what I actually wrote this for!
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7df7c019
  16. 12 2月, 2008 1 次提交
  17. 07 2月, 2008 1 次提交
    • S
      safecrlf: Add mechanism to warn about irreversible crlf conversions · 21e5ad50
      Steffen Prohaska 提交于
      CRLF conversion bears a slight chance of corrupting data.
      autocrlf=true will convert CRLF to LF during commit and LF to
      CRLF during checkout.  A file that contains a mixture of LF and
      CRLF before the commit cannot be recreated by git.  For text
      files this is the right thing to do: it corrects line endings
      such that we have only LF line endings in the repository.
      But for binary files that are accidentally classified as text the
      conversion can corrupt data.
      
      If you recognize such corruption early you can easily fix it by
      setting the conversion type explicitly in .gitattributes.  Right
      after committing you still have the original file in your work
      tree and this file is not yet corrupted.  You can explicitly tell
      git that this file is binary and git will handle the file
      appropriately.
      
      Unfortunately, the desired effect of cleaning up text files with
      mixed line endings and the undesired effect of corrupting binary
      files cannot be distinguished.  In both cases CRLFs are removed
      in an irreversible way.  For text files this is the right thing
      to do because CRLFs are line endings, while for binary files
      converting CRLFs corrupts data.
      
      This patch adds a mechanism that can either warn the user about
      an irreversible conversion or can even refuse to convert.  The
      mechanism is controlled by the variable core.safecrlf, with the
      following values:
      
       - false: disable safecrlf mechanism
       - warn: warn about irreversible conversions
       - true: refuse irreversible conversions
      
      The default is to warn.  Users are only affected by this default
      if core.autocrlf is set.  But the current default of git is to
      leave core.autocrlf unset, so users will not see warnings unless
      they deliberately chose to activate the autocrlf mechanism.
      
      The safecrlf mechanism's details depend on the git command.  The
      general principles when safecrlf is active (not false) are:
      
       - we warn/error out if files in the work tree can modified in an
         irreversible way without giving the user a chance to backup the
         original file.
      
       - for read-only operations that do not modify files in the work tree
         we do not not print annoying warnings.
      
      There are exceptions.  Even though...
      
       - "git add" itself does not touch the files in the work tree, the
         next checkout would, so the safety triggers;
      
       - "git apply" to update a text file with a patch does touch the files
         in the work tree, but the operation is about text files and CRLF
         conversion is about fixing the line ending inconsistencies, so the
         safety does not trigger;
      
       - "git diff" itself does not touch the files in the work tree, it is
         often run to inspect the changes you intend to next "git add".  To
         catch potential problems early, safety triggers.
      
      The concept of a safety check was originally proposed in a similar
      way by Linus Torvalds.  Thanks to Dimitry Potapov for insisting
      on getting the naked LF/autocrlf=true case right.
      Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
      21e5ad50
  18. 22 1月, 2008 1 次提交
    • J
      Avoid running lstat(2) on the same cache entry. · eadb5831
      Junio C Hamano 提交于
      Aside from the lstat(2) done for work tree files, there are
      quite many lstat(2) calls in refname dwimming codepath.  This
      patch is not about reducing them.
      
       * It adds a new ce_flag, CE_UPTODATE, that is meant to mark the
         cache entries that record a regular file blob that is up to
         date in the work tree.  If somebody later walks the index and
         wants to see if the work tree has changes, they do not have
         to be checked with lstat(2) again.
      
       * fill_stat_cache_info() marks the cache entry it just added
         with CE_UPTODATE.  This has the effect of marking the paths
         we write out of the index and lstat(2) immediately as "no
         need to lstat -- we know it is up-to-date", from quite a lot
         fo callers:
      
          - git-apply --index
          - git-update-index
          - git-checkout-index
          - git-add (uses add_file_to_index())
          - git-commit (ditto)
          - git-mv (ditto)
      
       * refresh_cache_ent() also marks the cache entry that are clean
         with CE_UPTODATE.
      
       * write_index is changed not to write CE_UPTODATE out to the
         index file, because CE_UPTODATE is meant to be transient only
         in core.  For the same reason, CE_UPDATE is not written to
         prevent an accident from happening.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eadb5831
  19. 18 1月, 2008 1 次提交
  20. 17 1月, 2008 1 次提交
  21. 07 1月, 2008 1 次提交
    • J
      diff: do not chomp hunk-header in the middle of a character · 23707811
      Junio C Hamano 提交于
      We truncate hunk-header line at 80 bytes, but that 80th byte
      could be in the middle of a character, which is bad.  This uses
      pick_one_utf8_char() function to make sure we do not cut a character
      in the middle.
      
      This assumes that the internal representation of the text is
      UTF-8.  This needs to be extended in the future but the optimal
      direction has not been decided yet.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      23707811
  22. 05 1月, 2008 3 次提交
    • J
      diff: remove lazy config loading · cae6c25a
      Jeff King 提交于
      There is no point to this. Either:
      
        1. The program has already loaded git_diff_ui_config, in
           which case this is a noop.
        2. The program didn't, which means it is plumbing that
           does not _want_ git_diff_ui_config to be loaded.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cae6c25a
    • J
      diff: load funcname patterns in "basic" config · e467193f
      Jeff King 提交于
      The funcname patterns influence the "comment" on @@ lines of
      the diff. They are safe to use with plumbing since they
      don't fundamentally change the meaning of the diff in any
      way.
      
      Since all diff users call either diff_ui_config or
      diff_basic_config, we can get rid of the lazy reading of the
      config.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e467193f
    • J
      add a "basic" diff config callback · 9a1805a8
      Jeff King 提交于
      The diff porcelain uses git_diff_ui_config to set
      porcelain-ish config options, like automatically turning on
      color. The plumbing specifically avoids calling this
      function, since it doesn't want things like automatic color
      or rename detection.
      
      However, some diff options should be set for both plumbing
      and porcelain. For example, one can still turn on color in
      git-diff-files using the --color command line option. This
      means we want the color config from color.diff.* (so that
      once color is on, we use the user's preferred scheme), but
      _not_ the color.diff variable.
      
      We split the diff config into "ui" and "basic", where
      "basic" is suitable for use by plumbing (so _most_ things
      affecting the output should still go into the "ui" part).
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9a1805a8
  23. 27 12月, 2007 1 次提交
  24. 20 12月, 2007 1 次提交
  25. 18 12月, 2007 1 次提交
  26. 14 12月, 2007 5 次提交
    • W
      Make "diff --check" output match "git apply" · 45e2a4b2
      Wincent Colaiuta 提交于
      For consistency, make the two tools report whitespace errors in the
      same way (the output of "diff --check" has been tweaked to match
      that of "git apply").
      
      Note that although the textual content is basically the same only
      "git diff --check" provides a colorized version of the problematic
      lines; making "git apply" do colorization will require more extensive
      changes (figuring out the diff colorization preferences of the user)
      and so that will be a subject for another commit.
      Signed-off-by: NWincent Colaiuta <win@wincent.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      45e2a4b2
    • W
      Unify whitespace checking · c1795bb0
      Wincent Colaiuta 提交于
      This commit unifies three separate places where whitespace checking was
      performed:
      
       - the whitespace checking previously done in builtin-apply.c is
      extracted into a function in ws.c
      
       - the equivalent logic in "git diff" is removed
      
       - the emit_line_with_ws() function is also removed because that also
      rechecks the whitespace, and its functionality is rolled into ws.c
      
      The new function is called check_and_emit_line() and it does two things:
      checks a line for whitespace errors and optionally emits it. The checking
      is based on lines of content rather than patch lines (in other words, the
      caller must strip the leading "+" or "-"); this was suggested by Junio on
      the mailing list to allow for a future extension to "git show" to display
      whitespace errors in blobs.
      
      At the same time we teach it to report all classes of whitespace errors
      found for a given line rather than reporting only the first found error.
      Signed-off-by: NWincent Colaiuta <win@wincent.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c1795bb0
    • J
      diff --check: minor fixups · da31b358
      Junio C Hamano 提交于
      There is no reason --exit-code and --check-diff must be mutually
      exclusive, so assign different bits to different results and allow them
      to be returned from the command.  Introduce diff_result_code() to factor
      out the common code to decide final status code based on diffopt
      settings and use it everywhere.
      
      Update tests to match the above fix.
      
      Turning pager off when "diff --check" is used is a regression.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      da31b358
    • W
      "diff --check" should affect exit status · 62c64895
      Wincent Colaiuta 提交于
      "git diff" has a --check option that can be used to check for whitespace
      problems but it only reported by printing warnings to the
      console.
      
      Now when the --check option is used we give a non-zero exit status,
      making "git diff --check" nicer to use in scripts and hooks.
      Signed-off-by: NWincent Colaiuta <win@wincent.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      62c64895
    • J
      xdl_diff: identify call sites. · c279d7e9
      Junio C Hamano 提交于
      This inserts a new function xdi_diff() that currently does not
      do anything other than calling the underlying xdl_diff() to the
      callchain of current callers of xdl_diff() function.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c279d7e9