0

When I'm trying to merge Git says:

foo.txt deleted in HEAD and modified in release

Actually, I didn't delete foo.txt in my branch, but moved it to a new place, a few times. I suspect that Git lost this multiple movement information and now thinks that I deleted the file and created a new one somewhere else.

Can I somehow inform Git where the file is located now?

yegor256
  • 102,010
  • 123
  • 446
  • 597
  • Did you used `git mv` to move the file? – Alvin Wong Oct 11 '12 at 10:41
  • Maybe the rename limit or the similarity is too low. Does git detect the renames when you do `git log --follow --stat new-name-of-foo.txt`? – robinst Oct 11 '12 at 10:50
  • @Alvin Wong, of course, I used `git mv`. @robinst, yes, `git log --follow --stat` shows full log (a year log) – yegor256 Oct 11 '12 at 10:55
  • @AlvinWong You don’t need to use `git mv` to perform moves. Git does not track moves or copies (just content and paths) but will try to identify moves/copies if they happened on the fly. – poke Oct 11 '12 at 12:57
  • @poke I heard that git doesn't even handle move and copy, but what do you mean `will try to identify moves/copies if they happened on the fly`? I don't understand. – Alvin Wong Oct 11 '12 at 15:13
  • @AlvinWong When a file is removed and another is added in the same commit, and they are similar, all Git frontend tools (log, diff etc.) will detect that it is actually the same file except the path changed. So it will show you that the file was just moved, instead of one being deleted and another being added. It will even accept small changes, so you can safely refactor stuff for a name change etc. The same applies to copies, where a new file is added that looks similar than one that already existed. – poke Oct 11 '12 at 21:15
  • @poke That's dependent on the rename limit, yeah? – kayaker243 Oct 12 '12 at 03:06
  • @kayaker243 What rename limit? – poke Oct 12 '12 at 10:13
  • When you rename a file 10 times, that's actually identical to renaming 1 time if you haven't tracked the process. If you actually tracked them it would be quite unwise... – Alvin Wong Oct 12 '12 at 11:12
  • @poke sorry, i meant the inexact file rename limit. – kayaker243 Oct 12 '12 at 18:57
  • 1
    If it’s all in a single commit, then there is only one rename detected (obviously). If you have 10 commits and you rename it once in each, each commit will show the rename, and if you do a diff between the first and the last commit (and the file didn’t change too much) then it will detect that rename as well. I.e. renaming detection is done in the commands that display the information to the user; none of the information is stored in the underlying data structure. – poke Oct 12 '12 at 23:27
  • 1
    Regarding the rename detection, you can customize the threshold Git requires for renames to be valid in the output commands. `git diff -M80` for example will detect moves if the file similarity is above 80%. If you want to detect copies to, you can use `-C80` instead. – poke Oct 12 '12 at 23:30

1 Answers1

0

This is how I solved the problem:

git rebase

I applied all my changes to the master branch, one by one, resolving conflicts incrementally.

yegor256
  • 102,010
  • 123
  • 446
  • 597