Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
This problem only arises if *both* files get renamed in the same commit. If only either one of those files is renamed in the same commit, history is retained.
They didn't get renamed at all. I merely copied one of them.
You mean: - You have two identical files in the repository. - Both files have a differing history. - The you copy one of those files, resulting in three identical files.
Yes, in that case, if the new name/directory seems closer to the "wrong" file, the history will be taken from the wrong file.
Then again, this is a very theoretical case, I've never seen this happen in practice; besides, if files end up being identical but with differing history, then in most cases, their history is related. It's rather unlikely that history is unrelated, but files end up identical.
In theory, yes. In practice, in code development projects, this problem rarely arises.
But can you fix it when it does?
The usual way to fix this was to fix the logic in git. The last time anyone had this problem and it needed to be fixed was more than a year ago.
Hints in the git repository could be generated to actually fix/prevent this problem, but for this to happen, the problem needs to become more common first; and it doesn't look very likely that it will occur a lot.