the rename won't be in your history because the tree and commit objects don't support renames

the tooling infers a rename based on the lack of a content change

Is there a difference?

Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.

So just make sure the moves and edits are in separate commits?

Yes, that's the standard workaround.

Absolutely, the inference is based on a set of heuristics and is often just plain wrong.

I've had one or two really annoying merges that were complicated by these renames. TIL thanks to these responses that it's not actually a rename.

`git mv` is just shorthand for `git rm` and `git add`. All Git knows is that there was a file called `oldfile` and there's now a file called `newfile`, and whether or not they have similar contents or filenames. It's only when you run `git status` or `git diff` or whatever that it actually tries to guess if anything was renamed. So what you're seeing isn't the rename being recorded in history but just that guess being correct. It's easy for it to become incorrect if you make some nontrivial changes or have multiple similar files.

The parent comment's suggestion is to commit each of these moves individually, which should guarantee that the detection algorithm will get it right. Will definitely pollute your history, though.

> If you rename the file using git

Does nothing. Git won't remember you did it.

> and that is the only change in your file

This always works, but it means you need to choose between flaky rename detection and weird extra rename-only commits that probably don't compile.