up vote 51 down vote favorite
12

I've moved a bunch of files around manually without thinking, and can't find a way to get git to recognize that the files are just moved and not actually different files. Is there a way to do this other than removing old and adding the new (and thus losing the history), or redoing all the changes with git-mv?

share|improve this question
5  
Git automatically picks up copies and moves of a file. Why do you say it doesn't pick up the moves? – Jeremy Wall Sep 16 '09 at 3:32
1  
Duplicate? stackoverflow.com/questions/433111/… ...some good answers at this other question (helped me at least!) – Drew Noakes Jun 11 '10 at 13:17
    
Edit: I just noted that "git log" works fine on a moved file as long as I call "git commit -a" first. – user907318 Aug 23 '11 at 8:37
2  
@JeremyWall I've found that git often gets moves of a file wrong unless I explicity use git mv. – Warren Dew Mar 16 '14 at 22:08
    
Possible duplicate of Is it possible to move/rename files in git and maintain their history? – Kristján Dec 9 '15 at 16:12
up vote 15 down vote accepted

I think it already does this. Now, I could be wrong, but I've read that git tracks files based on their contents not based on their position in the file system or based on delta/differences. In the stack I think it shows it as if the files are being removed and the then re-added, but I think I've tried this once and it still maintained the history, due to the aforementioned way that git tracks things.

Still would be helpful for someone to verify if I'm correct or not. Sorry if I misunderstood your question.

share|improve this answer
16  
This is correct. There should be no difference between moving a file (and using "git rm" and "git add" on the old and new files, respectively), and using "git mv". Michael: if the problem is that you are not seeing the pre-move history in "git log FILE", try using "git log --follow FILE". – Phil Sep 16 '09 at 3:36
6  
Didn't work for me. Git saw the file as being deleted and a new file being added. Not sure what I did wrong. Could be a bitbucket issue, because it looked as if Git detected the file as being renamed when I did the commit. – James McMahon May 21 '12 at 17:47
1  
it all depends on how different the file is after moving it, which is dumb. If you rename dummy.class to clean_refactor.clas, you will most probably change the contents of the file, by renaming the class name at least. These changes can make git not realize that dummy.class and clean_refactor.class belong to the same history :( – Rafa Jan 30 '13 at 14:31
1  
@JorgeIsraelPeña just renaming the file won't be a problem. But often you rename a file during some refactoring, and the changes in the code related to that refactoring will confuse git. – Rafa Jan 31 '13 at 23:32
1  
@JorgeIsraelPeña yes, I know. Hence my rant :) In svn the history of the file wouldn't get lost, including its refactoring. I would be able to see in the log that the class B used to be named A and was refactored into B. – Rafa Feb 3 '13 at 19:18
up vote 56 down vote

To have git remove files that are removed or moved already, just enter

git add -u
share|improve this answer
6  
+1: Thanks, that's exactly what was missing. When git status doesn't grok a move or rename, git add -u fixes it. – rsenna Dec 27 '11 at 13:03
8  
Can you explain what this is doing exactly? – OlivierBlanvillain Aug 22 '13 at 13:50
1  
@OlivierBlanvillain: 'git add -u' stages all files that git is tracking and have also changed in the working directory. Note that if you moved the file to a directory Git isn't tracking, 'add -u' won't detect the move. If you later add the destination directory to Git and re-do 'add -u', Git will then pick up the move correctly. – JS. Oct 21 '15 at 23:03
1  
This is the correct answer – xtian Mar 16 at 12:31
up vote 10 down vote

git doesn't track the history of individual files and it doesn't treat moves and copies specially, that is there is no special metadata that indicates that a move or copy occurred. Instead each git commit is a complete snapshot of the working tree.

If you want to see moves in git log you can supply -M in addition to an option that lists which files have changed, e.g.

git log --summary -M

git will look at the adjacent trees in the commit history and infer if any files where moved by each commit.

To find copies as well as renames you can use the -C option, you can supply it twice to make git look harder for possible copy sources at the expense of some performance.

git log --summary -M -C -C

Note, that as git doesn't store file history (only commit history), even if you did git rm and git mv the file, you wouldn't lose any history. All changes to the path would still be recorded and visible in a git log.

share|improve this answer
2  
You can also set diff.renames config variable to true either in .git/config (repository config), or in ~/.gitconfig (user's config). See git-config manpage for details. – Jakub Narębski Sep 16 '09 at 9:09
up vote 5 down vote

To better understand why Git does do rename detection instead of (more common) explicit rename tracking, and how git log path limiting works, you can read read Linus's ultimate content tracking tool blog post by Junio C Hamano, maintainer of Git (and references therein).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.