How does Git detect renames during a merge, and where does that detection break down?

## Git stores no renames This is the fact everything else follows from. A Git commit points at a tree, and a tree lists paths and blob ids. There is no "renamed from" field anywhere in the object model. `git mv` is a convenience that stages a deletion of one path and an addition of another; the resulting commit is indistinguishable from doing it by hand. Renames are therefore **inferred at read time** — by `git log --follow`, by `git diff`, and by the merge strategy — from the content itself. ## Why a merge cares Suppose one branch renames `parser.go` to `syntax/parser.go` while another branch fixes a bug inside `parser.go`. Without rename detection, the merge sees a file deleted on one side and modified on the other: a modify/delete conflict at best, a silently dropped bug fix at worst. With detection, Git recognises the rename and applies the other side's edits to the new path, producing the result a human would expect. ## How detection works Two stages: 1. **Exact renames.** A deleted path and an added path whose blob object ids are identical are the same content at a new location. This is cheap — a hash comparison — and catches pure moves. 2. **Inexact renames.** For the remaining unmatched additions and deletions, Git measures content similarity between candidates and pairs those above a threshold, by default around 50% similar. This step is quadratic in the number of candidates, which is why it is capped. Git also performs **directory rename detection**: when one side moves a whole directory and the other side adds new files to the old directory, the new files can be moved into the renamed directory. Where this is ambiguous — for example the directory's files went to two different destinations — Git reports a conflict rather than guessing. ## The knobs - `-X find-renames=<n>` sets the similarity threshold for the merge, for example `-X find-renames=30` to match more aggressively at the cost of false pairings. - `-X no-renames` turns rename detection off for the merge. - `merge.renames` is the config equivalent for enabling or disabling merge rename detection. - `merge.renameLimit` and `diff.renameLimit` cap how many candidate paths inexact detection will consider. Exceeding the cap makes Git emit a warning that inexact rename detection was skipped, and the merge proceeds as if there were no renames. ## Where it breaks down - **Rename plus heavy rewrite.** Move a file and rewrite most of its body in the same commit and similarity drops below the threshold, so the pair is not detected. The other side's edits then have nowhere to go. - **Splits and merges of files.** Rename detection pairs one deletion with one addition. A file split into three modules, or three files merged into one, has no such pairing to find. - **Divergent renames.** Both sides rename the same file to different paths — a rename/rename conflict — and Git cannot choose for you. - **Rename versus delete.** One side renames, the other deletes: the conflict is real and requires a human decision about intent. - **Limit exceeded.** Large restructures produce thousands of candidates; when the rename limit is hit, detection is skipped wholesale and the merge degrades into add/delete pairs, often with a storm of conflicts. - **Generated or boilerplate files.** Highly similar files can be paired with the *wrong* partner, which is the false-positive side of the same heuristic. ## Practical mitigations The highest-value habit is **structural**: perform large moves in a commit that does nothing else. A pure-move commit is trivially detectable — the blobs are identical, so exact detection catches everything without touching the similarity stage or the rename limit. Mixing a move with edits is what pushes similarity down. When a merge has already gone wrong, the diagnostic path is to check whether Git warned about the rename limit, retry with a raised limit or a lower `find-renames` threshold, and inspect the conflicting paths to see whether they are actually a moved-and-edited pair. ## What an interviewer is testing The key insight is that rename tracking is *inference, not record-keeping*. Candidates who say "Git tracks renames with `git mv`" have the model wrong, and that wrong model makes every downstream failure inexplicable. Once you state the inference model, the failure cases follow naturally: anything that lowers content similarity, or makes the pairing one-to-many, or makes the search too expensive, defeats a heuristic that was never a guarantee in the first place.