Nico Williams <nico@xxxxxxxxxxxxxxxx> writes: > I don't find file rename heuristics to be "simple", and they're often I think you need to re-read what Tytso wrote before reacting. He never said rename and copy heuristics is simple. His statement was that choosing *NOT* to record the "file A was renamed to B and C was copied to D in this commit" in commit objects can be thought as a choice to keep the system simple. But the decision not to record renames and copies in commits is not about simplicity but it is more about correctness. People record wrong renames and not all renaming changes are made with "git mv". Through your GUI IDE, you may choose "Copy file" menu and make a copy of an existing file F to file G, and edit file G extensively and record the result in a commit. No matter how heavy the edit after copying is, your IDE would remember that G came originally by copying from F so it should be able to record the fact that G was copied from F in the resulting commit. But recording that as a copy may be a *wrong* thing to do in the first place. The IDE cannot guess *why* you copied F to G in the first place. Perhaps it was because your project requires you to reproduce boilerplate license notice in the comment at the beginning of each and every file, and copying an existing file as a whole, removing everything after that initial boilderplate comment, and write everything else afresh was the easiest way for you to work. If you inspect the resulting change brought in by the commit, with intelligence, a human may say "G is a completely new file, even though it shares the leading boilerplate comment with F and every other file in the project". Your IDE wouldn't say that. We designed not to etch such wrong renames/copoies in stone by recording them at the commit time. Instead we compare the before and after image to intuit the _intention_ of what the user wanted to do _when_ you _ask_ (i.e. when you run "git diff" or "git log"). This has an additional benefit that the heuristics to find out about renames and copies *can* be improved long after commits are made, so a commit that used to be misidentified to have renamed a file (when there is no such renaming) may later say that a file is removed and a new file is made independently with newer version of Git.
