Just make sure to use 'git mv' for all your files so the history can be tracked. 'git log myfile' will only show the history for that file, but 'git blame' will follow the line changes across file moves.
That aside, there are some many productivity and tooling gains around organizing your project properly, that it is worth history discontinuities.
Also, I've found that the worse the project organization is, the less likely the team is to separate out different fileset changes into different commits to keep a useful history, or make the use of the git history at all outside of looking at a few recent commits or or sometimes looking at the last release. I've heard this as very circular arguments. Can't re-org because we loose history. Can't maintain good history because the project is too disorganized.
Has behavior for `git mv` changed? Last time I investigated, the command was convenience to `git add` after a `mv` with a single command. Git doesn't actually explicitly track renames, it leverages some sort of auto-detection based on file content similarity.
Still good to use the command, just keep in mind git isn't really treating it any different than a normal `mv` followed by `git add`.
This might not be the forum for it, but I have a question about this - I thought git was supposed to be pretty smart about detecting renames, but in my experience (on Windows) it never does, and I always have to use `git mv`. What's the deal with this?
Even if rename detection is enabled, git will only try to identify renames if it wouldn't take too much time (since IIRC it's a O(#files^2) operation).
Thus, there's a config "diff.renameLimit" and "merge.renameLimit" that tells git to only detect renames if less than N files are affected.
I have personally been burned by this before, and there usually is a default value set in most git clients.
That aside, there are some many productivity and tooling gains around organizing your project properly, that it is worth history discontinuities.
Also, I've found that the worse the project organization is, the less likely the team is to separate out different fileset changes into different commits to keep a useful history, or make the use of the git history at all outside of looking at a few recent commits or or sometimes looking at the last release. I've heard this as very circular arguments. Can't re-org because we loose history. Can't maintain good history because the project is too disorganized.