Is there a difference between git mv and the MS-DOS move?

Question

Does it make a difference if I move Git tracked files with the git mv command as opposed to just moving the files with MS-DOS move or the Windows Explorer?

Back in the Subversion days, it was necessary to use for example the TortoiseSVN SVN Move versioned files here command to keep the history intact.

  • Git shows the error “does not appear to be a git repository fatal: The remote end hung up unexpectedly”
  • git conflicts with remote, need to keep local changed
  • Git subtree cannot detect new commits in sub folder
  • What happens to unsynced changes when the parent repos of a github fork is deleted?
  • Merging after refactoring - detecting moved file parts
  • How to push/pull/fetch different repositories which are belong to different user of BitBucket on one computer
  • I would have expected it to work the same way in Git, but a test (see example below) showed that Git detects by itself that the file has been moved and that the history is kept intact.

    So why use git mv at all?

    Example

    C:\test>git init
    C:\test>mkdir folder
    C:\test>cd folder
    C:\test\folder>echo "1" > file.txt
    C:\test\folder>git add .
    C:\test\folder>git commit -m "Initial commit"
    C:\test\folder>echo "2" >> file.txt
    C:\test\folder>git add .
    C:\test\folder>git commit -m "Update file.txt"
    C:\test\folder>move file.txt ..
    C:\test\folder>cd ..
    
    C:\test>git status
    On branch master
    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:    folder/file.txt
    
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
    
            file.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")
    
    C:\test>git add -A
    C:\test>git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
    
            renamed:    folder/file.txt -> file.txt
    
    C:\test>git commit -m "Moved file.txt with the move command"
    

    The entire history has been retained despite not using git mv and Git says that is has detected a renaming.

    C:\test>git log --oneline --follow file.txt
    6bd3c05 Moved file.txt with the move command
    5b55aea Update file.txt
    5b9b255 Initial commit
    

  • Why doesn't the command `gem list` include gems installed with bundler's :git option?
  • Separate files in Git
  • Git/GitHub - change default location for cloned repository without changing HOME variable?
  • Git branch overwrites master when merging without offering conflicts
  • Git: removing a file from being versioned, but not deleting it
  • What's the Mercurial equivalent for git hash-object and how do I get the hash of a certain commit?
  • 2 Solutions collect form web for “Is there a difference between git mv and the MS-DOS move?”

    git mv does the staging for you as well, so that you don’t need to git rm olfdfile and git add newfile after physically moving the file via mv/MOVE/explorer.exe.

    This is on purpose.

    When you use git mv it will index the modifications for you

    If you do it manually with your OS, you will need to do

    git add -A <previous-path-to-file-that-was-moved>
    git add <new-path-to-file>
    

    So that git understands you actually renamed the file.

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