Git doesn't recognize renamed and modified package file

Question

I had a java file called package/old/myfile.java. I had committed this file through git. I then renamed my package to new so my file was in package/new/myfile.java.

I now want to commit this file rename (and content changes) to git.

When I do git status I get

# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    package/old/myfile.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       package/new/myfile.java

I've tried adding the new and rming the old and vice versa, I keep getting

$ git status
# On branch develop
# Changes to be committed: 
#        delete:    package/old/myfile.java
#        new file:  package/new/myfile.java

I can't do mv old new because the old file doesn't exist and so I get bad source error.

Is there anything else I can try?

I've tried some of the multiple answers on SO for similar problem, but they haven't worked.

Answer 1

The relevant section from the git book explains this.

Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later.

What this means is that if you move a file and then make significant changes git will not know that it was a move. It will see a file deleted and a new file created because the new file doesn't look like the old one. To get around this people often git mv files, commit the move, and then make changes. In your situation you can do

git reset # Move changes from index to working copy
git checkout package/old/myfile.java # Undo delete
git mv package/old/myfile.java package/new/myfile.java # Move file

Answer 2

Move the file back, then commit it, and put the actual move into a separate commit. Git does not record moves (or renames) as such, but can recognize them afterward based on content. If the content changes, it can't detect the move properly. Therefore it's common practice to split moves and changes into two commits.