How does file identity survive a rename-plus-edit in the same commit?

[RozuniFix72]

We scan a monorepo where a quarterly refactor keeps renaming directories while editing the moved files. Concretely: one commit both moves src/net/socket.rs to src/net/transport.rs AND changes ~40% of its lines.

From the outside I see the co-change atlas still links the moved file with its old neighbors, so the rename tracking clearly works - but I want to understand the mechanics before I trust it on aggressive histories:

1. What does the parser key identity on when git log --name-status shows an R100 vs an R060? At what similarity threshold does a rename stop being "the same file" and become a delete+add pair? Is the threshold configurable in the CLI or hard-coded in parse.rs?
2. When a rename and a content edit land in the SAME commit, the churn number for that path - is the edit churn attributed to the new path only, or is it split across the old/new path pair? I am asking because our churn windows around refactor commits look suspiciously quiet.
3. Does rename tracking consider the content of the commit (e.g. a comment in the message like "rename x to y"), or purely the name-status stream? We have histories from an export tool that does not emit R-status lines at all, and I want to know whether identity is lost or degraded to something weaker (e.g. path-prefix heuristics).

[MacroMate8]

Three answers, in order of what actually happens:

1. Identity keys on the name-status stream, with a similarity floor. For R<NN> records the parser keeps the file identity whenever the recorded similarity clears the floor (currently 50, matching git's own -M default) - below that it degrades to a break: the old path terminates its identity, the new path starts a fresh one. The floor is a parser constant, not a CLI flag yet; if you need a different cut, that is the one line to change, but raise it, never lower it - a low floor is how unrelated files start sharing identity and every downstream metric quietly lies.

2. Churn from a rename+edit commit is attributed to the new path only, as a single entry. It is not split across the pair - splitting would double-count the window. The co-change EDGE, however, is recorded against the pair as it existed in that commit: the edge references the old path on the old side. That is exactly why your refactor commits look quiet in churn windows - one commit, one churn entry - while the atlas still shows the linkage. Churn windows measure edits, the atlas measures co-occurrence; they answer different questions by design.

3. Purely the name-status stream. Commit messages are never parsed - they are not a data format, and treating prose as evidence is how tools develop folklore instead of behavior. For your export tool: if it cannot emit R-status lines, run the raw history through git log --name-status -M yourself before feeding it to RepoHelix; without R-records the parser has no rename evidence at all, and it will NOT fall back to path-prefix guessing. A silent heuristic fallback is worse than a visible data gap - you would get a confident-looking atlas built on luck.