How git tracks file renaming information?

Question

$ git init Project
$ cd Project
$ echo "function getRandomNumber () { return 3; }" > FirstName.JS
$ git add .
$ git commit -m v1

As a next step, I will rename the FirstName.JS while its contents survive intact:

$ mv FirstName.JS SecondName.JS
$ git add .
$ git commit -m v2

For the following commit I'm going to rename the file and tweak its contents:

$ mv SecondName.JS ThirdName.JS
$ echo "function getRandomNumberWithASeed (seed) { return seed * 3; }" >> ThirdName.JS
$ git add .
$ git commit -m v3

If we put in the show using the v2 commit as an argument, the command will indicate that the same file was renamed. However for the v3 commit output would different: SecondName.JS was deleted and ThirdName.JS was created. It's inconsistency I'm willing to avoid.

1. Why does Git think of the v2 and v3 commits in different way? I suppose the matter with it Git finds the blob object which is the same as one needed for the SecondName.JS (v2) (this blob object was created for the v1 commit). The opposite situation arises with the v2 and v3 commits (contents of their blob objects are distinguishable).

2. How is Git able to show information about file renaming (for example, we can see it through the show command)? In fact, tree objects only store file names and links to blob objects. Based on this, it's impossible to claim whether the one file was renamed or one file was deleted and a new appeared. Does Git store some meta-data for this purpose or are there its heuristics?

Answer 1

git does not track file renames, period.

Various commands will report their best guess about renames after the fact, based on seeing pairs of path A deleted and path B added where the old content at A is "similar enough" to the new content at B.

There are settings you can use to change the threshold for "similar enough", or turn rename detection off. See the git config docs (look for things like diff.renames and diff.renameLimit). That can eliminate any perceived "inconsistency" if you want; though most of the time the default behavior seems to be what's useful in my experience. (The main reason for disabling this is if the rename detection checks are taking too much time, e.g. in repos with a lot of add and delete activity.)