Keep git history file while changing its location

Question

I’ve created a branch from master in order to address a file migration from es5 syntax to es6.

In that branch, I change the migrated file’s location as well as its unit test file and I do some other modifications.

I've tried those commands:

git checkout master
git remote update
git pull
git checkout -b <branch-name>

git mv path/to/file.js new/path/to/file.js
git mv path/to/file.spec.js new/path/to/file.spec.js

Then I commit my changes and only after that first commit, I start modifying the files.

The problem I encounter is that on my pull request the unit test file is recognized as a file that has been modified on the other hand the file itself, « file.js » is recognized as a file that has been deleted and recreated.

It is a problem because I will loose the history of that file.

What would be a solution to that issue ?

Answer 1

tl;dr: Don't worry about it, because it actually doesn't matter!

Why? Git actually doesn't store renames at all. Anytime you compare two commits, Git may detect a rename, or a separate add and delete, depending on the algorithm used at the time (which can be configured) and how different the files are. Note that git mv is just a convenience.

Most PR views compare the merge-base of your source and target branches, with the tip commit of your source branch. This means the in between commits are not looked at it, so that commit you made that only moved the files isn't considered by the PR view. The reason one file is detected as a rename and the other isn't, is presumably due to the amount of changes between the files, and one had enough to push it over the rename detection threshold. However, when you view the history of each file separately, having that in-between commit you created will still help when tracing the history. You can prove this by testing it locally:

1. Simulate the PR's merge locally by checking out master and merging in your source branch.
2. View the history of each file (git log <filepath>). You should see both follow the rename.
3. Now compare the merge commit with it's first parent and you'll (probably) see that only one looks like a rename, and the other doesn't. (git diff @~1 @)