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.
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 开发者_JAVA百科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.
I've noticed this too. I think "--find-renames=90" will be stricter than the default.
From the git diff documentation http://git-scm.com/docs/git-diff
-M[n] --find-renames[=n] 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.
-C[n] --find-copies[=n] Detect copies as well as renames. See also --find-copies-harder. If n is specified, it has the same meaning as for -Mn.
精彩评论