How to make git mark a deleted and a new file as a file move?

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?

  • Git push failed updating remote server info
  • git merge should ignore one directory
  • Can one clone a Git LFS repo without installing Git LFS?
  • How to install plugin in Rails 3 from local git repository or other local source?
  • Git - undoing git rm
  • How to share files across git repositories?
  • “git blame” a file access control modifier
  • How to exclude south migrations from public repositories?
  • Git clone error in Xcode
  • Push a commit in two branches with Git
  • How to logout / switch accounts in Sourcetree
  • Deploying websites with git security
  • 12 Solutions collect form web for “How to make git mark a deleted and a new file as a file move?”

    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.

    Do the move and the modify in separate commits.

    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/                |   10 +++++-----
         lib/Gentoo/{ => Repository}/     |    2 +-
         lib/Gentoo/{ => Repository}/ |   12 ++++++------
         lib/Gentoo/{ => Repository}/  |   10 +++++-----
         lib/Gentoo/{ => Repository}/    |   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/                |   36 ------------------------
     lib/Gentoo/            |   51 ----------------------------------
     lib/Gentoo/             |   41 ---------------------------
     lib/Gentoo/          |   10 +++---
     lib/Gentoo/Repository/     |   36 ++++++++++++++++++++++++
     lib/Gentoo/Repository/ |   51 ++++++++++++++++++++++++++++++++++
     lib/Gentoo/Repository/  |   41 +++++++++++++++++++++++++++
     lib/Gentoo/Repository/    |   55 +++++++++++++++++++++++++++++++++++++
     lib/Gentoo/               |   55 -------------------------------------
     9 files changed, 188 insertions(+), 188 deletions(-)

    git help log

           Detect renames.
           Detect copies as well as renames. See also --find-copies-harder.

    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%.

    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.

    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: and has been logged as a bug to fix here: 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.

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

    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.

    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.

    Use git mv command to move the files, instead of the OS move commands:

    I had this problem recently, when moving (but not modifying) some files.

    The problem is that Git changed some line endings when I moved the files, and then wasn’t able to tell that the files were the same.

    Using git mv sorted out the problem, but it only works on single files / directories, and I had a lot of files in the root of the repository to do.

    One way of fixing this would be with some bash / batch magic.

    Another way is the following

    • Move the files and git commit. This updates the line endings.
    • Move the files back to their original location, now that they have the new line endings, and git commit --amend
    • Move the files again and git commit --amend. There is no change to the line endings this time so Git is happy

    When I edit, rename, and move a file at the same time, none of these solutions work. The solution is to do it in two commits (edit and rename/move seperate) and then fixup the second commit via git rebase -i to have it in one commit.

    Git Baby is a git and github fan, let's start git clone.