Git thinking added/removed files are renamed

Question

I've never run into this before, as Git has always considered renamed files as added/removed in my experience, but we have generated files in the repo that are based on modifications of another file in the repo (it was originally designed this way by someone else and we decided to utilize it in the restructured repo), and it's considering every new iteration of these files as "renamed" (97% similarity) even though the old files are completely obliterated and the new are created (with their own filename partially based on a checksum).

We're using BitBucket to merge pull requests and it's become a pain to try to merge branches now as it thinks there were file renames on both sides of the merge when simply files were added or deleted.

Any solution to this?

Answer 1

Git actually does not recognize file renames, and it also doesn’t care about it. What Git does is track the content of the full repository. If you modify files, or add files, or remove files, Git just takes another independent snapshot of the repository and creates a commit for it.

Some porcelain tools, that are those commands that end users usually work with, do have a notion of recognizing file renames. Or at least, they try to detect it. Since Git has no notion of renames, they can just do good guesses. For that, they make comparisons of the content. If a file content before is to a certain percentage similar to a file content afterwards, then it’s considered either a rename or a copy (copy if the original file is still there).

But that’s really just a visual aid to help you confirm your actions in case you really performed a merge. After all, if you rename a whole folder, you are actually removing all the files in that original folder, and adding all files in the new folder. At least that’s what Git sees and what it keeps track of. But for the user looking at the change, it’s more helpful to see that the files all stayed the same and were just moved to a new path.

The bottom line is that you do not need to care about this. It’s just an indicator the front-end tools of Git give you. It has no impact at all on what Git actually does, and it does not make a difference whether something is considered a rename or a file was deleted and readded somewhere else.

Answer 2

how to merge renamed or similar file(s)?

You can also try the -Xrename-threshold=X to lower the rename similarity detection threshold.

git merge ... -Xrename-threshold=<20> 
// Where 20 is the % of similarity in files

---

diff.renameLimit
    The number of files to consider when performing the copy/rename
    detection; equivalent to the git diff option -l.

merge.renameLimit
    The number of files to consider when performing rename detection
    during a merge; if not specified, defaults to the value of
    diff.renameLimit.

From git help merge (also in git help pull):

rename-threshold=<n>
    Controls the similarity threshold used for rename detection.
    See also git-diff(1) -M.

From git help diff:

-M[<n>], --find-renames[=<n>]
    Detect renames. 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.