summaryrefslogtreecommitdiff
path: root/contrib/convert-objects
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2010-08-13 12:17:45 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2010-08-13 12:17:45 -0700
commit44c48a909ae3d49afcaedb2b2cd042d1e329ee93 (patch)
tree3aefdac22c9d9e52d1f59176169ed03f764920e0 /contrib/convert-objects
parentdiff --follow: do not waste cycles while recursing (diff)
downloadtgif-44c48a909ae3d49afcaedb2b2cd042d1e329ee93.tar.xz
diff --follow: do call diffcore_std() as necessary
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 1da6175 (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: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/convert-objects')
0 files changed, 0 insertions, 0 deletions