git mv and changes and similarity index
Asked Answered
T

1

7

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.

Trichromatic answered 8/1, 2019 at 4:10 Comment(0)
Y
9

It is based on the diff similarity index

If n is 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., -M5 becomes 0.5, and is thus the same as -M50%.
Similarly, -M05 is 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)

Yiddish answered 8/1, 2019 at 5:41 Comment(3)
Yeah, mv in a commit, change in another seems a good choice. Thanks.Trichromatic
Is it possible during the pull request workflow to break the move detection even with an initial git mv commit followed by a modify commit(s)? Basically if one always does git mv followed by a modification commit the file rename will always be picked up correctly regardless of how many modifications were made to that file. Is that accurate?Trunnion
@Trunnion I believe it is. Separating mv from modification is safer (but one rarely thinks to split their changes that way)Yiddish

© 2022 - 2024 — McMap. All rights reserved.