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.
- IntelliJ VCS log windows became empty
- Commit early, commit often - does it mean “push” early, often in GIT?
- Similar program to Team Foundation Server
- How to get file's contents on Git using LibGit2Sharp?
- Sparse checkout in Git 1.7.0?
- Ignoring an already checked-in directory's contents?
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!
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%.