Question: is --no-renames in NumstatParse intentional for stats line counting?

[txf0096]

Observed Behaviour

git-ai stats reports inflated added-line counts for commits that include
file renames. A pure rename (no content change) is counted as N lines deleted

• N lines added, rather than 0.

Root Cause Analysis

Commit e1e7965 ("Harden internal git profiles") introduced
InternalGitProfile::NumstatParse and switched get_git_diff_stats
(stats.rs:657) and get_range_diff_stats (range_authorship.rs:361) to use
this profile.

The profile injects --no-renames into the underlying git show/diff --numstat call. This disables git's rename detection:

• Before e1e7965: pure rename → 0\t0\t{old => new} → 0 lines ✓
• After e1e7965: pure rename → treated as delete-all + add-all → full file size doubled in stats

Affected commands: git-ai stats HEAD, git-ai stats A..B, and the line count shown in status.

Question

Was this the intended trade-off when hardening against hostile diff.*
configs? If not, would removing --no-renames from NumstatParse's injected
options be the right fix? The strip_profile_conflicts function already strips
--find-renames, --find-copies, -M, -C flags from user-supplied args,
which may be sufficient protection.

(Note: --no-renames in diff_added_lines is used for per-line AI attribution accuracy and is a separate concern.)

[svarlamov]

Will look into this! I think the no renames was initially added for performance, but I'll verify. Agree the stats shouldn't increment for pure renames