My repository has large number of large files.
They are mostly data (text).
Sometimes, I need to move these files to another location due to refactoring or packaging.
git mv foo bar
git commit -m "modify"
git cat-file -s HEAD:bar
By design, if you move a file inside a Git repository without changing content, creating a commit will only store new metadata (a.k.a. tree objects) to represent new file location. Since content is unchanged, Git doesn't need to create new blob object to store file content. So "commit size" should be rather small.
Since you say that diff size is huge, I suppose that some file content is modified along with relocation. This would be a reason for "commit size" to be huge.
In both case, you can try to shrink .git directory size with the command
git gc --prune --aggressive
git mv foo bar git commit -m "modify" git cat-file -s HEAD:bar
These commands create a new commit, but the since the foo/bar file content has not changed, Git won't store anything new but the new file name. In fact, in you example,
git cat-file -s HEAD:foo before rename and
git cat-file -s HEAD:bar after will give you the same result, since its the same content (same blob in .git/objects).
I think you are mis-interpreting things that git does internally. Have a look to Git objets to get further explanations.
Remember that git tracks content, not files.