How does Git know that the file has been renamed?

Question

What algorithm does Git use to determine if a file has been renamed?

This is what git status was created just a few minutes before:

Information marked with a yellow field is incorrect. In fact, there was no such renaming. The files views/file/create.php and views/file/index.php were really deleted half an hour after creating a completely new set of two files - views/logo/create.php and views/logo/index.php .

Both sets of files may seem (before Git) quite similar, but the fact remains - these are not the same thing, renamed files. This is a complete new set of files created in different directories half an hour before deleting the first set of files.

Since the information provided by Git is incorrect, I would like to talk about my curiosity and why I ask.

Answer 1

From Wikipedia :

Renames are handled implicitly, not explicitly. A common complaint with CVS is that it uses the file name to identify its change history, so moving or renaming a file is impossible without either interrupting its history or renaming the history and thereby making the history inaccurate. Most version control systems after CVS resolve this by providing the file with a unique long-lived name (a kind of index number) that survives renaming. Git does not write such an identifier, and this is claimed as an advantage. [34] [35] Source code files are sometimes split or merged, as well as simply renamed, [36] and recording this as a simple rename would freeze an inaccurate description of what happened in a (unchanged) history. Git addresses the problem by detecting renames when viewing the history of snapshots rather than recording it when creating a snapshot. [37] ( In short, this file is in revision N, the file with the same name in revision N-1 is its default. However, when there is no file with similar names in version N-1, Git searches for a file that existed only in revision N-1 and is very similar to the new file. ) However, it requires more intensive work with the CPU every time the history is viewed, and the number of heuristic settings. This mechanism is not always work; sometimes a file that is renamed with changes to the same commit is read as deleting the old file and creating a new file. Developers can get around this limitation by renaming and changing separately.