git mv will keep the history. Else it would be useless.
Most of the time even if you move the file yourself, git rm the old one, and git add the new one… git is smart enough to know it is the same file. (and keep the history)
…but always better to git mv to be sure.
Caveat: all of this assumes the move is within the same repository. Moving stuff from one repository to another and keeping history is a lot trickier (though I’ve done it: see blender loader as a working result of that)
As I know, Git doesn’t care about the way how you’ve made change. It calculates the difference and finds matches by its own algorithm. When you see in a Git history (using git log, for example) that file was moved - that’s because Git detects very similar content with different pathname through the history, not because you’ve made a change with mv. All these commands rm, mv, add are just a convenient way to choose which files (or even lines) should be included to next commit and nothing more.
By history I mean when I click the file from the web interface, before the move, it will list all commits for any file selected. Afterwards, the history still shows in the history tab of the github desktop, and atom editor, but the history button on the web interface is wiped out only showing the last commit.
Ok, this is why I hate CLI so much, everything I read says “Hey, renaming a folder from CLI is easy!”
That tells me what I am doing must be wrong or there is something else thats changed in git and everybody but me knows the secret.
git mv oldname newname
git mv -f oldname newname
Rather than renaming oldname to newname, it just creates a new directory newname and moves oldname into it. Nothing in any doc says this is expected behavior unless the folder already exists, but it doesnt.