Prevent git from treating delete & new file w/ changes as a move

Question

I'm using Git to track changes to XML configurations for virtual machines. Many of the XML configurations are similar, with just a few fields that are different. I often delete VM configurations and add new ones. When adding these changes to the repo, Git treats it as a file rename, with just a few changes. I could see why git would do this, and understand it's use case.

I'm wondering if there's a way to prevent that, and instead have git treat it as a file deletion with a new file creation instead. When looking at the commit logs, it would be much easier to discern "oh, looks like on this day I deleted this VM and created a new one"

Delete a file; commit your changes. THEN add the new file, and commit it. — mah, Apr 23 '13 at 15:02

Schnouki · Accepted Answer · 2013-04-23T15:18:28.500

14

Renames are only something shown in the output, internally they are stored just as regular deletions and creations.

If you want to disable the renames detection, you can use the --no-renames option:

git log --stat --no-renames

(also works with git diff, git show, etc.)

If you don't want to add this option all the time, you can add it to your config:

git config diff.renames false

edited Apr 23 '13 at 15:18

answered Apr 23 '13 at 15:10

Schnouki

7,527
3
33
38

Unfortunately i am faced with a situation where this doesn't work. There is a stash repository for code reviews. A previously created folder containing files similar to new created ones are showing up as moved in pull request. This is not desired and won't get a code review through. I originally did git config renames set to false in my local branch before pushing changes, but that didn't solve any thing. They still show up as moved files in the diff. Any ideas? – fkl Jun 09 '15 at 20:41
@fayyazkl No idea, sorry. The `git config diff.renames` option is only used when computing the diff to display it, not when committing or pushing, so if you want it to be effective it should be added to the code review system... which is probably a bad idea in the general case. IMHO, you should just explain why this shows up this way in your PR, and hope that the reviewers understand how renames work in git... – Schnouki Jun 10 '15 at 09:50
Thanks alot @Schnouki - yeah i tried for a while and then gave up. Did exactly the same as you suggested. It just made code review a bit difficult for others. But putting a comment explaining that was the best way to do that. – fkl Jun 10 '15 at 14:58

score 4 · Answer 2 · answered Apr 23 '13 at 15:09

Don't worry, Git is just displaying the change as a rename as it looks like a rename. It's not storing it as a rename as there is no way for Git to do this. Rename detection happens on commit display, not at record time.

You can use git show --no-renames to avoid rename detection even if you have it on by default.

Prevent git from treating delete & new file w/ changes as a move

2 Answers2