How do I tell Git it got moves/renames wrong (false positives)
I’m merging two branches in git, having a week worth of work each and some of the files were moved or renamed and modified.
Git seems to get the stuff completely wrong in some cases and it says file a was moved to file b when in reality they are totally unrelated.
- Git Ignore Files per Branch
- Git merging hotfix branch into feature branch, then removing hotfix branch?
- What are currently the problems with Git on Windows
- How to do rebase --interactive in a Windows GUI
- Can i use git version control application without github?
- Can you prevent default-push, but allow pull?
I’m having quite a few such false positives (roughly 25%). I would like to influence the algorithm Git uses to figure out whether a file was moved, renamed or is new.
- I’d like to assign higher priority to names. (file a was moved from folder foo to folder b) yet git insists that it was renamed to be file b in folder foo – totally unrelated)
- I’d like to bump up the similarity index above which Git considers a file to be rename/move
I know I read somewhere I can do the latter and I hope I can do the former too, but my googling skills are failing me today.
One Solution collect form web for “How do I tell Git it got moves/renames wrong (false positives)”
I’ve noticed this too. I think “–find-renames=90” will be stricter than the default.
From the git diff documentation
Detect renames. If n is specified, it is a 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.
Detect copies as well as renames. See also –find-copies-harder. If n is specified, it has the same meaning as for -Mn.