There's a solution which works most of the time, and it works equally well in Subversion and Git. Divide up the change into two commits: 1. Move the file verb

There's a solution which works most of the time, and it works equally well in Subversion and Git. Divide up the change into two commits: 1. Move the file verbatim. 2. Change the file as necessary. Subversion will remember the move because it always does — Subversion stores changesets internally, and those changesets contain history metadata. Git won't track the move, but when you run `git log --follow` later it detects that the file was moved because the content of the file that was added was the same as something which existed before. It's a little awkward if only a small portion of a file was migrated, though. In such a case, you may just have to fall back to documenting in the commit message that code was moved. This approach has another benefit: it is easy to review. The first commit can be validated as "verbatim move — check!". Then the logical change can be validated with effort proportional to the amount that was changed. In contrast, if you lump them all together, it can be hard to discern what changed when presented with a huge diff containing mostly verbatim move but also a few subtle changes.