Does Git treat add/remove as a rename?

Question

This may be more appropriate as an issue in whatever issue tracker/forum Git uses, but I thought I'd get an SO confirmation/explanation first:

I have a repo tracking a bunch of installer executables.

Let's say foo-1.0.exe is already in the repo.

I now add foo-2.0.exe in the same directory (git add foo-2.0.exe). Next, I remove foo-1.0.exe (git rm foo-1.0.exe).

I expect Git status to show me one added file and one removed file. Instead, I get this:

On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
renamed: foo-1.0.exe -> foo2.0.exe

That's a WTF for me... is Git using some sort of heuristic to guess that 2.0 is an update to 1.0... I can see how that might make sense, but I don't think I want it to do that in this case.

Answer 1

You are correct that Git is using a heuristic. Git tracks only content, so the repository only knows that there used to be a foo-1.0.exe and now there is a foo-2.0.exe. In your case, git status is using the available information to guess that there might have been a rename (plus some minor changes, your two files are probably pretty similar). This guess will not affect what is recorded in the repository.

This philosophy of tracking only content and not deltas allows Git to evolve and provide better and better tools for navigating repository history. Eventually, Git will provide a way to track the evolution of a particular bit of code, at the function or even line level, through renames or refactoring or any other code modification. This can be done without the repository having to store this information beforehand.