Git - 将文件标记为新文件而不是移动/复制

Question

Is there any way to force git to consider a file as new instead of moved/copied?

Use case:

1. I have a large file, index.js
2. I'm factoring out a small class from that file into Helper.js (only 10% of the index.js ) and renaming index.js to MyLib.js . MyLib.js will have some minor changes related to importing symbols from Helper.js .
3. I need to recreate index.js as a new, 2-line file, that only re-exports symbols from Helper.js and MyLib.js .

I want the commit history to record renaming index.js to MyLib.js and treat the 2-line index.js as new, but git instead treats MyLib.js as completely new, and index.js as having lost 99% of its contents, down to only those 2 lines.

Answer 1

The short answer is : no, git does not allow you to store information about how files were moved.

git tracks content , not diffs .

When git displays the information :

$ git diff --name-status HEAD^ HEAD
M    fileA          # fileA has been modified
R    oldB -> fileB  # fileB has been renamed
A    fileC          # fileC has been created

it actually has computed this information by comparing the contents of the two commits. It has not stored the information : "actually fileC was copied from fileA, and fileA was re-created as a new file".

If two files have the same name in both commit, git diff will always compute "this file has been modified".

---

Option 1 : keep the history you have, and live with it.

Option 2 : you could try to do it in two commits

• create a first commit, where the only action is renaming file index.js to MyLib.js ,

  • if you need the code to "work" -- for example so that unit tests or integration tests can be run on this commit -- update other modules so that they import MyLib.js instead of index.js

• create a second commit, where you apply the modifications you actually want to see

  • extract a small class from MyLib.js to Helper.js ,
  • create a new index.js file with two lines and exported symbols,
  • if you had modified the imports in the first commit, modify them again in this second commit.

---

With option 2, some git commands ( git rebase , or git log --follow for example) would detect the renaming step in the repo's history, because they always inspect the history one commit at a time.

Some other commands, that do not look at a commit per commit diff but at a "global" diff, would still behave as option 1.

For example : if you open a Merge Request (think github , gitlab , Azure Devops ...), the Merge Request interface would still present you with :

• file index.js has been modified,
• file MyLib.js is an entirely new file

Answer 2

I am assuming that you used git mv to move that file, which is why Git is reporting it as having been moved. Something like this:

git mv file.txt newfolder

But Git doesn't know what it can't see, so if you move the file from the filesystem Git will see the file in the new location as being new:

mv file.txt newfolder

You can git add this file to add it to the index. After this, you could optionally delete the original the file from Git:

git add newfolder/file.txt
git rm file.txt

Keep in mind that this means that Git won't be able to track the history of this file using this approach. While using git mv also would make it difficult to track the history of the moved file, it would have at least made it somewhat possible.

Answer 3

Git is pretty smart figuring out when a file has been moved (if you delete the file and add it in the new location in the same commit, Git will figure out that the file has been moved).

If you actually want the file to be considered as "new" instead of "moved", probably the best option is to delete and add the file into its new location in separated commits.