up vote 231 down vote favorite
48

I've moved a file manually and then I've modified it. According to Git, it is a new file and a removed file. Is there any way to force Git into treating it as a file move?

share|improve this question
3  
For a given file old_file.txt, then git mv old_file.txt new_file.txt is equivalent to git rm --cached old_file.txt, mv old_file.txt new_file.txt, git add new_file.txt. – Jarl Sep 4 '12 at 8:18
1  
Jarl: no it's not. If there are also changes within the file, git mv will not add them to the cache, but git add will. I prefer to move the file back so that I can use git mv, then git add -p to review my change set. – dhardy Feb 10 '14 at 15:59
    
please checkout my script github.com/Deathangel908/python-tricks/blob/master/… – deathangel908 Dec 9 '15 at 9:54
    
Possible duplicate of Is it possible to move/rename files in git and maintain their history? – Michael Freidgeim Apr 12 '16 at 7:09
up vote 214 down vote accepted

Git will automatically detect the move/rename if your modification is not too severe. Just git add the new file, and git rm the old file. git status will then show whether it has detected the rename.

additionally, for moves around directories, you may need to:

  1. cd to the top of that directory structure.
  2. Run git add -A .
  3. Run git status to verify that the "new file" is now a "renamed" file

If git status still shows "new file" and not "renamed" you need to follow Hank Gay’s advice and do the move and modify in two separate commits.

share|improve this answer
26  
Clarification: 'not too severe' means that the new file and old file are >50% 'similar' based on some similarity indexes that git uses. – pjz Oct 19 '10 at 20:10
58  
Something that hung me up for a few minutes: if the renamed files and deleted files are not staged for committing then they will show up as a delete and a new file. Once you add them to the staging index it will recognize it as a rename. – marczych Mar 14 '12 at 1:41
10  
It is worth mentioning that when speaking of "Git will automatically detect the move/rename". It does so at the time you use git status, git log or git diff, not at the time you do git add, git mv or git rm. Further speaking of detecting rename, that only makes sense for staged files. So a git mv followed by a change in the file may look in git status as if it considers it as a rename, but when you use git stage (same as git add) on the file, it becomes clear that the change is too large to be detected as a rename. – Jarl Sep 4 '12 at 8:14
2  
One thing worth mentioning is that if you are deep inside a directory structure that you have moved files into, travel to the top of the tree before doing git add -A . to pick up the move. – jrhorn424 Mar 5 '14 at 16:32
1  
The real key seems to be to add both the new and old locations in the same git add, which as @jrhorn424 suggests, should probably just be the whole repo at once. – brianary Aug 24 '15 at 18:57
up vote 44 down vote

Do the move and the modify in separate commits.

share|improve this answer
3  
I understand that Git is can handle moves and modifications at the same time. When programming in Java and using an IDE, renaming a class is both a modification and a move. I understand that Git even should be able to automatically figure it out when there's a move (out of a remove and a creation). – Pablo Jan 11 '09 at 16:19
    
Perl requires this too, and I have never not had Git detect the move/rename. – jrockway Jan 12 '09 at 15:17
4  
@jrockway, I had. Happens easily with small files, I guess they "become 'too different' to mean a move". – ANeves Dec 15 '10 at 16:24
    
Yeah, it's probably a matter of how different they are. I did a refactoring which involved moving 80 files around and changing them at the same time.. Needless to say, git regarded them as deletions/additions and I had to re-do it in 2 steps. 1. Move file, stage, commit 2. Change file, stage, commit – Konstantinos Sep 21 '12 at 8:33
1  
Is there any way to do this automated? I have many files in the index, want to first commit the move, and then the change, but it's hard to do manually – ReDetection Feb 12 '16 at 11:52
up vote 36 down vote

It's all a perceptual thing. Git is generally rather good at recognising moves, because GIT is a content tracker

All that really depends is how your "stat" displays it. The only difference here is the -M flag.

git log --stat -M

commit 9c034a76d394352134ee2f4ede8a209ebec96288
Author: Kent Fredric
Date:   Fri Jan 9 22:13:51 2009 +1300


        Category Restructure

     lib/Gentoo/Repository.pm                |   10 +++++-----
     lib/Gentoo/{ => Repository}/Base.pm     |    2 +-
     lib/Gentoo/{ => Repository}/Category.pm |   12 ++++++------
     lib/Gentoo/{ => Repository}/Package.pm  |   10 +++++-----
     lib/Gentoo/{ => Repository}/Types.pm    |   10 +++++-----
     5 files changed, 22 insertions(+), 22 deletions(-)

git log --stat

commit 9c034a76d394352134ee2f4ede8a209ebec96288
Author: Kent Fredric
Date:   Fri Jan 9 22:13:51 2009 +1300

    Category Restructure

 lib/Gentoo/Base.pm                |   36 ------------------------
 lib/Gentoo/Category.pm            |   51 ----------------------------------
 lib/Gentoo/Package.pm             |   41 ---------------------------
 lib/Gentoo/Repository.pm          |   10 +++---
 lib/Gentoo/Repository/Base.pm     |   36 ++++++++++++++++++++++++
 lib/Gentoo/Repository/Category.pm |   51 ++++++++++++++++++++++++++++++++++
 lib/Gentoo/Repository/Package.pm  |   41 +++++++++++++++++++++++++++
 lib/Gentoo/Repository/Types.pm    |   55 +++++++++++++++++++++++++++++++++++++
 lib/Gentoo/Types.pm               |   55 -------------------------------------
 9 files changed, 188 insertions(+), 188 deletions(-)

git help log 

   -M
       Detect renames.

   -C
       Detect copies as well as renames. See also --find-copies-harder.
share|improve this answer
41  
Sorry if this seems a bit pedantic, but "Git is generally rather good at recognising moves, because GIT is a content tracker" seems like a non-sequitur to me. It's a content tracker, yes, and perhaps it happens to be good at detecting moves, but the one statement doesn't really follow from the other. Just because it's a content tracker the move detection isn't necessarily good. In fact, a content tracker could have no move detection at all. – Laurence Gonsalves Sep 10 '10 at 23:48
4  
+1: perceptual – ANeves Dec 15 '10 at 16:32
    
Very nice answer. But one question: At least what you see with git log -M -C --find-copies-harder might be more compact than what git stores in the commit (for example if you copied or renamed a very big file and git didn't detect this). Is there a way to detect such things at commit time? – Daniel Alder Oct 13 '13 at 14:51
    
If you rename a directory containing massive assets (with no actual change) then git add it, Git may sometimes fail at detecting that this is a rename. This has a major impact as this will push a new instance of your blob. Not that perceptual. – Warren Seine Feb 27 '14 at 7:41
    
@WarrenSeine when you rename a directory, the SHA1's of the files in that directory do not change. All you have is a new TREE object with the same SHA1s. There's no reason a directory rename would cause significant data changes. – Kent Fredric Feb 27 '14 at 21:53
up vote 20 down vote

git diff -M or git log -M should automatically detect such changes as a rename with minor changes as long as they indeed are. If your minor changes are not minor, you can reduce the similarity threashold, e.g.

$ git log -M20 -p --stat

to reduce it from the default 50% to 20%.

share|improve this answer
1  
Is it possible to define threshold in the config? – ReDetection Feb 12 '16 at 11:56
up vote 14 down vote

This is a quick solution if you've renamed a file, made some changes to it, Git doesn't realize it's a rename, and you haven't committed your changes. Let's say the file was named blah and now it's named foo:

  1. Rename foo to a temp name:

    mv foo foo.tmp

  2. Checkout blah:

    git checkout blah

  3. Rename blah to foo so that Git knows about it:

    git mv blah foo

  4. Now rename foo.tmp back to foo.

    mv foo.tmp foo

This last step is what gets your changed content back into foo.

share|improve this answer
18  
This process serves no purpose. git doesn't add any metadata for renames, git mv is simply a convenience for a git rm/git add pair. If you've already done 'mv bar foo', then all you have to do is make sure that you've git add foo and git rm bar before making the commit. This could be as done as a single git add -A command, or possibly a git add foo; git commit -a sequence. – Charles Bailey Oct 9 '09 at 6:48
9  
All I know is that before I did it, Git didn't recognize it as a move. After I did this, Git recognized it as a move. – user186821 Oct 15 '09 at 0:35
4  
It recognizes it as a move. But it also has the change as an unstaged change now. Once you add the file again, git breaks the move/modify into a deleted/added again. – Michael Piefel Feb 22 '12 at 8:30
4  
This process would work if you git commit after step 3, otherwise it is incorrect. Also, @CharlesBailey is correct, you could as easily do a normal mv blah foo at step 3 followed by a commit and get the same results. – DaFlame Feb 7 '14 at 15:36
1  
"This process serves no purpose." - It serves a purpose when git has gotten confused and thinks a file has been deleted, and another file has been added. This clears up Git's confusion and marks the file as moved explicitly without having to do intermediate commits. – Danack Jun 6 '15 at 14:50
up vote 9 down vote

If you're using TortoiseGit it's important to note that Git's automatic rename detection happens during commit but the fact that this is going to happen isn't always displayed by the software beforehand. I had moved two files to a different directory and performed some slight edits. I use TortoiseGit as my commit tool and the Changes made list showed the files being deleted and added, not moved. Running git status from the command line showed a similar situation. However after committing the files, they showed up as being renamed in the log. So the answer to your question is, as long as you haven't done anything too drastic, Git should pick up the rename automatically.

Edit: Apparently if you add the new files and then do a git status from the command line, the rename should show up before committing.

Edit 2: In addition, in TortoiseGit, add the new files in the commit dialog but don't commit them. Then if you go into the Show Log command and look at the working directory, you'll see if Git has detected the rename before committing.

The same question was raised here: https://tortoisegit.org/issue/1389 and has been logged as a bug to fix here: https://tortoisegit.org/issue/1440 It turns out it's a display issue with TortoiseGit's commit dialog and also kind of exists in git status if you haven't added the new files.

share|improve this answer
2  
You are right, even if TortoiseGit shows delete + add, even if git status shows delete + add even if git commit --dry-run shows delete + add, after git commit I see rename and not delete + add. – qub1n May 9 '14 at 11:40
    
I'm pretty sure the automatic rename detection happens during history retrieval; in the commit it is always add+delete. That also explains the schizophrenic behavior you describe. Hence the options here: stackoverflow.com/a/434078/155892 – Mark Sowul Mar 24 '16 at 18:59
up vote 5 down vote

If you're talking about git status not showing the renames, try git commit --dry-run -a instead

share|improve this answer
4  
Awesome. Why doesn't git status show that but --dry-run does? – Evan Carroll Aug 17 '15 at 23:56
    
Amazed! How does this work? I have the same question as @EvanCarroll. – Parth Feb 28 at 6:34
up vote 0 down vote

For me it worked to stash save all the changes before the commit and pop them out again. This made git re-analyze the added / deleted files and it correctly marked them as moved.

share|improve this answer
up vote 0 down vote

There is a probably a better “command line” way to do this, and I know this is a hack, but I’ve never been able to find a good solution.

Using TortoiseGIT: If you have a GIT commit where some file move operations are showing up as load of adds/deletes rather than renames, even though the files only have small changes, then do this:

  1. Check in what you have done locally
  2. Check in a mini one-line change in a 2nd commit
  3. Go to GIT log in tortoise git
  4. Select the two commits, right click, and select “merge into one commit”

The new commit will now properly show the file renames… which will help maintain proper file history.

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.