I have a somewhat confusing question in Git.
Lets say, I have a file dir1/A.txt committed and git preserves a history of commits
Now I need to copy the file into dir2/A.txt (not move, but copy).
I know that there is a git mv command but I need dir2/A.txt to have the same history of commits as dir1/A.txt, and dir1/A.txt to still remain there.
I'm not planning to update A.txt once the copy is created and all the future work will be done on dir2/A.txt
I know it sounds confusing, I'll add that this situation is on java based module (mavenized project) and we need to create a new version of code so that our customers will have the ability to have 2 different versions in runtime, the first version will be removed eventually when the alignment will be done. We can use maven versioning of course, I'm just newbie to Git and curious about what Git can provide here.
Unlike subversion, git does not have a per-file history. If you look at the commit data structure, it only points to the previous commits and the new tree object for this commit. No explicit information is stored in the commit object which files are changed by the commit; nor the nature of these changes.
The tools to inspect changes can detect renames based on heuristics. E.g. git diff has the option -M that turns on rename detection. So in case of a rename, git diff might show you that one file has been deleted and another one created, while git diff -M will actually detect the move and display the change accordingly (see man git diff for details).
So in git this is not a matter of how you commit your changes but how you look at the committed changes later.