Renames

Renames

It's a little more subtle... During development, files are always being created and destroyed and great swaths of code moved between them. The filename is just a temporary label. It's the content that is key.

Git will tell you "File A in tree 1 is 78% the same as File B in tree 2." The developer then knows that file B derives heavily from file A. One day git will also be able to tell you that "File C is 95% the same as parts of file A, and file D is 98% the same as parts of file A." This makes it pretty clear that file A was split into files C and D. Git just follows the content, no more, no less.

"Sure," you say, "svn mv and cp can show this and it's much easier to use!" (or Arx or insert favorite CMS here) So let's consider more real-world problems. What if you scatter the functions in file A across 5 different files, 3 of which already exist. Consider, for instance, the great USB reorg. Git still happily tells you exactly what happened, whereas file-based CMSes fall flat or, at the very least, need a colossal amount of hand-holding. Git encourages broad refactoring. By locking the filename to particular content, other CMSes tend to discourage it.

Git tells you _exactly_ what happened. Where did you get the idea that it guesses?

"But it's not suitable for every development project or style."

I doubt anybody would disagree with this!