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.
Git will not remove a file from just the working directory; the regular rm command may be used for that purpose. Removing a file from your directory and the index does not remove the file's history from the repository.
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).
In Git's case, it will try to auto-detect renames or moves on git add or git commit ; if a file is deleted and a new file is created, and those files have a majority of lines in common, Git will automatically detect that the file was moved and git mv isn't necessary.
Git will automatically detect the move/rename if your modification is not too severe. Just git add the new file, and git rm the old file. git status will then show whether it has detected the rename.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With