When a file is renamed with git mv, the commit will show rename from and rename to, and in pull request shows the same, which is good. But when a file is git mved then changed, it looks there is a certain threshold that when number of lines changed exceeded it, it will no longer show as renaming, instead it is show as old file deleted and new file added. So my question is is this threshold a well defined number? and is there any other way to make it better, mainly because in pull request diff, when the two files are no considered renamed, the diff won't show side by side, which makes the review difficult.
git mv and changes and similarity index
Viewed 1260
1 Answers
It is based on the diff similarity index
If
nis specified, it is a threshold on the similarity index (i.e. amount of addition/deletions compared to the file’s size).For example,
-M90%means Git should consider a delete/add pair to be a rename if more than 90% of the file hasn’t changed.Without a
%sign, the number is to be read as a fraction, with a decimal point before it. I.e.,-M5becomes0.5, and is thus the same as-M50%.
Similarly,-M05is the same as-M5%.To limit detection to exact renames, use
-M100%.The default similarity index is 50%.
More generally, it is better to mv/rename first a file, commit, then do some modifications.
You can do both is said modifications are minor compared to the rest of the file (typical case: refactoring where just the name of the package changes)
Related