1. 25 8月, 2010 1 次提交
  2. 23 8月, 2010 1 次提交
  3. 22 8月, 2010 2 次提交
  4. 21 8月, 2010 9 次提交
  5. 20 8月, 2010 3 次提交
  6. 19 8月, 2010 1 次提交
  7. 16 8月, 2010 1 次提交
  8. 14 8月, 2010 2 次提交
    • J
      diff --follow: do call diffcore_std() as necessary · 44c48a90
      Junio C Hamano 提交于
      Usually, diff frontends populate the output queue with filepairs without
      any rename information and call diffcore_std() to sort the renames out.
      When --follow is in effect, however, diff-tree family of frontend has a
      hack that looks like this:
      
          diff-tree frontend
          -> diff_tree_sha1()
             . populate diff_queued_diff
             . if --follow is in effect and there is only one change that
               creates the target path, then
             -> try_to_follow_renames()
      	  -> diff_tree_sha1() with no pathspec but with -C
      	  -> diffcore_std() to find renames
      	  . if rename is found, tweak diff_queued_diff and put a
      	    single filepair that records the found rename there
          -> diffcore_std()
             . tweak elements on diff_queued_diff by
             - rename detection
             - path ordering
             - pickaxe filtering
      
      We need to skip parts of the second call to diffcore_std() that is related
      to rename detection, and do so only when try_to_follow_renames() did find
      a rename.  Earlier 1da6175d (Make diffcore_std only can run once before a
      diff_flush, 2010-05-06) tried to deal with this issue incorrectly; it
      unconditionally disabled any second call to diffcore_std().
      
      This hopefully fixes the breakage.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      44c48a90
    • J
      diff --follow: do not waste cycles while recursing · 39f75d26
      Junio C Hamano 提交于
      The "--follow" logic is called from diff_tree_sha1() function, but the
      input trees to diff_tree_sha1() are not necessarily the top-level trees
      (compare_tree_entry() calls it while it recursively descends into
      subtrees).  When a newly created path lives in somewhere deep in the
      source hierarchy, e.g. "platform/", but the rename source is in a totally
      different place in the destination hierarchy, e.g. "lang-api/src/com/...",
      running "try_to_find_renames()" while base is set to "platform/" is a
      wasted call.
      
      We only need to run the rename following at the very top level.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39f75d26
  9. 13 8月, 2010 4 次提交
  10. 12 8月, 2010 7 次提交
  11. 10 8月, 2010 9 次提交