1

How can I stop git from detecting rename of files when I do git add and git rm?

I removed many files at different paths under the working tree, like 

tests/case066/chkpy000/active_set010.py
..
tests/case068/chkpy000/active_set010.py
tests/case069/chkpy000/active_set011.py
..
tests/case086/chkpy000/active_set011.py
tests/case087/chkpy000/active_set012.py
..
tests/case140/chkpy000/active_set012.py

I removed these files not by git rm but by rm of bash. Some of the files (i.e., those with the same name) had the same contents, while others had similar contents to each other.

I created new files in the directories where those removed files existed, like

tests/case066/chkpy000/active_set013.py
..
tests/case068/chkpy000/active_set013.py
tests/case069/chkpy000/active_set013.py
..
tests/case086/chkpy000/active_set013.py
tests/case087/chkpy000/active_set013.py
..
tests/case140/chkpy000/active_set013.py

The all new files have the same contents, and they are similar to the deleted ones.

Now, if I try to stage the changes by git rm <deleted_files> and git add <created_files>, or by git add --all tests, git seems to detect a few of the changes as renames and the others delete and add. In fact, the rename is detected across directories, which does not make sense. How can I let git simply stage the deletion and addition without detecting any rename?

(It would be better if there is a way to specify the rename pairs manually, but I would be glad with simply disabling the rename detection.)

Edit

I found a similar question,

How can I prevent git from thinking I did a rename

I also see in the comments and answer to this question as well as in other places that rename information is not stored in git database but is generated from it. So, maybe I could ignore the result of the rename analysis if it's wrong, but I feel a bit uneasy.

I ended up making two commits, first for the created files and second for the deleted files. This won't break build at each of these commits in my case, but may not be good for other cases.

norio
  • 3,652
  • 3
  • 25
  • 33
  • git's rename detection is just "UI-sugar", internally renaming is no different than removing one and adding another file – tkausl Oct 28 '17 at 05:15
  • Why is it important to disable the rename detection? – janos Oct 28 '17 at 05:20
  • Because the result of rename detection is wrong. If it's just a 'sugar', not important, and wrong, I don't want to see it. Is it still important to keep the rename detection enabled? – norio Oct 28 '17 at 05:27

1 Answers1

3

You can try again your rm/add after typing:

git config diff.renames false

But that might only affect only git diff Porcelain (git diff, git log).
Otherwise, this is just the result of using a similarity index, and does not influence how Git will store those (deleted/added) objects (an identical renamed file will still be stored only once).

If you really do not want those rename detections at git status, a workaround is to make, as the OP eventually did, two commits:

  • one for deletion
  • one for addition

But a git log -C might detect the renamed files.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250