# Tracking renamed files in Git DevFeed: [Tracking renamed files in Git]() Original publisher: [Read original article]() Author: Ole Begemann Published: 2025-12-15T15:51:35Z Content type: tutorial Language: en Sources: [Ole Begemann]() Topics: [Git](), [Algorithm]() Tags: [algorithm](), [git](), [structure]() ## AI overview The article explains that Git stores repository snapshots rather than explicit file-rename records. During diffing, Git uses customizable similarity heuristics to infer likely renames. It recommends making file renames in a standalone commit, separate from substantial content edits, to improve identity tracking. ## Source excerpt Git famously doesn't track file renames. That is, Git doesn't store the information "file A has been renamed to B in commit X". Instead, Git stores snapshots of the repository at each commit. It then uses a (customizable) heuristic during diffing to guess at likely renames: "File B in commit X is new, and file A has been deleted. B is 90 % identical to A's previous contents, so A was probably renamed to B." This behavior is very much by design: Git FAQ: Why does Git not "track" renames? Linus Torvald's explanation why Git doesn't track renames (2005-04-15) (archived copy) Linus Torvald's email is worth reading. It's well-reasoned and I agree with his arguments: Tracking renames is a superficial solution that fixes only part of the actual problem: how do you track the history of a particular piece of information, which may be much smaller (a single line) or larger (the design of an entire subsystem) than a file, depending on context. Shifting the task of history tracking from commit time to search time allows the search algorithm to do a much better job, because it can be tweaked to the structure of the underlying data. And yet, I still miss the ability to explicitly register a rename operation with Git. Maybe this is because the history tracking tools we have are not as good as what Linus Torvalds envisioned in 2005. Or because sometimes the file is a good enough unit of granularity for history tracking, even if imperfect. Use a separate commit for the rename Git's heuristics work great if renaming a file is all you do in a commit. Tracking only becomes a problem if the renaming coincides with substantial changes to the file's contents in the same commit. Unfortunately, this happens very frequently in my experience: more often than not, my reason for renaming a file is that I made substantial edits and now the filename no longer represents the file's contents. The golden rule: To track a file's identity across renames, perform the rename in a standalone commit, sepa