Thank you for the explanation! The bug report comes from an attempt to write examples to demonstrate what those command line options do and how they interact, so currently there is no real-world case where the limit needs to be loosen. It would be good to make the limit configurable if many people want it. For me I just hope the documentation and the actual behavior can be consistent. On Wed, Sep 11, 2024 at 6:48 PM Jeff King <peff@xxxxxxxx> wrote: > > 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
