New SDK drop… how to instruct git that certain files are moved?

I’ve previously been working on an SDK that I’ve now received a new code drop for.

When starting on this project I created an import branch on which I committed the SDK and I merged that to my master branch as a first commit.

But now there’s this new version of the SDK and I noticed that a lot has changed in the directory structure. Quite a lot files have been moved into subdirectories to improve the structuring of the codebase I guess.

So I want to have a new commit on the import branch so merging it to the master would be easier but I don’t know how to instruct git that the files have been moved.

git mv file_a dir_a/file_a

…doesn’t work because the target file exists. So I tried:

git mv -f file_a dir_a/file_a

Isn’t what I want either since the target location get overwritten with the content of the old version.

I also tried gitmoving everything first to resemble the new directory structure and then copying everything over. But git still sees it as a remove of the old file and an addition of the new file.

So what is the way to proceed here?
Any tips/pointers are welcome!

  • Git keyword substitution like those in Subversion?
  • Ignore all dir's but one
  • Which part of HUDSON_HOME should I put under source control?
  • Is it good practice to store binary dependencies in source control?
  • How can I generate the difference between 2 commits which ignore spaces
  • Visual Studio 2015 Source Control System
  • Haskell stack and version control
  • How can I find the git version of a source code dump?
  • One Solution collect form web for “New SDK drop… how to instruct git that certain files are moved?”

    git does not track moves so you can’t do this directly. git tries to identify moved files on the fly by looking to see if a file that was added is a lot like a file that was deleted. So just git rm the old files and git add the new files and see what git status says. You can modify the behaviour of rename detection in git log, here’s a copy of the relevant section from git help log.

    -M[<n>], --find-renames[=<n>]
       If generating diffs, detect and report renames for each commit. For following
       files across renames while traversing history, see --follow. If n is
       specified, it is a threshold on the similarity index (i.e. amount of
       addition/deletions compared to the file’s size). For example, -M90% means git
       should consider a delete/add pair to be a rename if more than 90% of the file
       hasn’t changed. Without a % sign, the number is to be read as a fraction, with
       a decimal point before it. I.e., -M5 becomes 0.5, and is thus the same as
       -M50%. Similarly, -M05 is the same as -M5%. To limit detection to exact
       renames, use -M100%.
    
    Git Baby is a git and github fan, let's start git clone.