Menu
What algorithm Git uses to determine, that some file was renamed?
This is, what git status produced just a few minutes before:
Information marked with yellow box is incorrect. There was actually no such kind of rename. Files views/file/create.php and views/file/index.php were truly deleted half hour after a completely new set of two files -- views/logo/create.php and views/logo/index.php was created.
Both files sets may seem (to Git) quite similar, but the fact remains -- these are not the same, renamed files. This is a complete new set of files, created in different directory about half an hour before deleting first set of files.
Since information provided by Git is incorrect, I'd like to feed my curiosity and that's why I'm asking.
334
Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot. [37] (Briefly, given a file in revision N, a file of the same name in revision N−1 is its default ancestor.
There's no way to tell for sure whether a file has been renamed. When a file is renamed, its inode number doesn't change. (This may not be true for “exotic” filesystems, such as network filesystems, but it's true for all “native” Unix filesystems.)
You can use the command line to rename any file in your repository. Many files can be renamed directly on GitHub, but some files, such as images, require that you rename them from the command line.
Step 1: Open GitHub. Step 2: Open the repository to rename any file in that repository. Step 3: Open the file which we want to rename. Step 4: Click the edit button and rename the file.
From Wikipedia:
Renames are handled implicitly rather than explicitly. A common complaint with CVS is that it uses the name of a file to identify its revision history, so moving or renaming a file is not possible without either interrupting its history, or renaming the history and thereby making the history inaccurate. Most post-CVS revision control systems solve this by giving a file a unique long-lived name (a sort of inode number) that survives renaming. Git does not record 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 the (immutable) history. Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot.[37] (Briefly, given a file in revision N, a file of the same name in revision N−1 is its default ancestor. However, when there is no like-named file in revision N−1, Git searches for a file that existed only in revision N−1 and is very similar to the new file.) However, it does require more CPU-intensive work every time history is reviewed, and a number of options to adjust the heuristics. This mechanism does not always work; sometimes a file that is renamed with changes in the same commit is read as a deletion of the old file and the creation of a new file. Developers can work around this limitation by committing the rename and changes separately.
63
answered Sep 28 '22 05:09
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
