Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How can I prevent git from thinking I did a rename

Tags:

git

I have two files index.html and template.html. I moved most of index.html into template.html and now git thinks that I did a rename when I add both files. Is it possible to prevent this in specific cases?

like image 252
Kit Sunde Avatar asked Feb 22 '13 19:02

Kit Sunde


People also ask

Does git detect file rename?

Git keeps track of changes to files in the working directory of a repository by their name. When you move or rename a file, Git doesn't see that a file was moved; it sees that there's a file with a new filename, and the file with the old filename was deleted (even if the contents remain the same).

How does git know rename?

Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot. [37] (Briefly, given a file in revision N, a file of the same name in revision N−1 is its default ancestor.

What happens when you rename a file in git?

It does not rename or move the actual file, but rather deletes the existing file and creates a new file with a new name or in another folder.


2 Answers

There is an "accepted" answer, but it does not give any hint on how to answer the question.

The correct answer, from git-log(1) and git-diff(1) is:

   --no-renames        Turn off rename detection, even when the configuration        file gives the default to do so. 
like image 25
mat Avatar answered Sep 21 '22 17:09

mat


Why Git Thinks Your Files Are Copies

Git tracks content, not filenames. As a result, if two files have substantially similar content, git will think you copied or renamed the file. If you read git-log(1), you will learn:

The similarity index is the percentage of unchanged lines, and the dissimilarity index is the percentage of changed lines. It is a rounded down integer, followed by a percent sign. The similarity index value of 100% is thus reserved for two equal files, while 100% dissimilarity means that no line from the old file made it into the new one.

So, assuming your similarity index is 100%, git will think that's a copy. Your best bet is to add a sensible log message or note (see git-notes(1) for more on that) to explain what's going on if you don't think git is doing the right thing.

Adjusting the Similarity Index

You might also try adjusting the values git uses for considering something a copy or rename. The manual for git-log(1) says:

-M[<n>], --find-renames[=<n>]  If generating diffs, detect and report renames for each commit. For following files across renames while traversing history, see --follow. 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.  -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 -M<n>. 

Again, this won't help you if the files are mostly similar, but you can certainly use these values to tune how similar they need to be in order to be considered copies or renames. Your mileage may vary.

like image 175
Todd A. Jacobs Avatar answered Sep 20 '22 17:09

Todd A. Jacobs