On Tue, Sep 10, 2024 at 11:07:19PM +1200, Han Jiang wrote: > Thank you for filling out a Git bug report! > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? (Steps to reproduce your issue) > > cd '/'; cd '/'; rm --force --recursive -- './test_git2'; mkdir "$_"; cd "$_"; > mkdir --parents -- './repo'; > git init './repo' > echo -e 'a\nb\nc\nd\ne\nf\ng\nh\ni\nj' >'./repo/file1' > echo -e '0\n1\n2\n3\n4\n5\n6\n7\n8\n9' >'./repo/file2' > git -C './repo' add './file1' './file2' > mv './repo/file2' './repo/file3' > mv './repo/file1' './repo/file2' > git -C './repo' add --intent-to-add './file3' > git -C './repo' diff --break-rewrites='50%/50%' --find-renames='50%' > > What did you expect to happen? (Expected behavior) > > `git diff` outputs: file1 rename to file2, file2 rename to file3 > > What happened instead? (Actual behavior) > > `git diff` outputs: file1 remove all content, file2 complete rewrite, > file3 add all content It's because your toy example is too small. Try: seq 400 >repo/file2 instead of the 0-9 input, which will then do what you expect. There is a hard-coded MINIMUM_BREAK_SIZE limit which requires that one of the files must be at least 400 bytes, presumably to avoid awkward corner cases in the heuristics for very small files. That comes from eeaa460314 ([PATCH] diff: Update -B heuristics., 2005-06-03), so quite long ago. But I'm not sure if any science went into determining it. Do you have a real (non-toy) case where it should be triggering but isn't? I wonder if we should consider making that hard-coded limit configurable somehow. -Peff
