2

$ git status:

renamed:    test.foo -> database/migrations/.gitignore

What's actually happened is I've deleted test.foo, which was empty, and created an empty .gitignore.

I assume it thinks the files are the same one because they were both empty. This is a bit misleading for the history later - I'd rather it was accurate.

How do I solve this and get it to show the deleted file as deleted and the new file as created?

bcmcfc
  • 25,966
  • 29
  • 109
  • 181
  • 5
    The "rename" is not actually in git history - it's a run-time heuristics to print pretty messages for `git status` and some other git commands. – abyss.7 Jul 15 '14 at 08:26

2 Answers2

4

You could:

git rm --cached .gitignore
git commit -m "delete test.foo"
git add .gitignore

That would help separate the two operations.

  • First untrack .gitignore while keeping test.foo as deleted in the index
  • Then track (git add) .gitignore.

That will avoid the rename heuristic (see "How does Git track history during a refactoring?") to get confused.

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

There is no reason to do anything. Internally, renames in git are not possible - they are always treated as remove followed by append. However, git has some heuristics to help people understand that file was renamed. These heuristics are based on how much new file looks like old one.

Like in your case, this heuristic may be "too" helpful. However, this is likely to be solved by newer git releases, because object store format does not need to change to treat these heuristics differently.

You might want to submit bug request on http://git-scm.com/community so empty files are never treated as renames.

mvp
  • 111,019
  • 13
  • 122
  • 148
  • I agree you don't have to do anything, but I like to keep different tasks in different commits anyway: in the OP's case, isolating the deletion of `test.foo` shouldn't hurt. – VonC Jul 15 '14 at 08:45
  • @VonC: it depends on context. However, polluting git history with extra bogus commit when your commit logically needs add one and remove another does not seem like decent solution either – mvp Jul 15 '14 at 08:49