Branch merge bug

A friend showed me this reduced test case. It seems to work fine with bzr and hg. Is this a git bug?

git version 1.6.3.1

Initialized empty Git repository in /Users/lut4rp/Code/tester/.git/

[master (root-commit) 9983161] initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 fil

* master
  new

# On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: fil -> fila #

[master 9de0953] renamed to fila
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename fil => fila (100%)

Switched to branch 'new'

rm 'fil'

[new 5914271] renamed, heavily modified
 2 files changed, 2 insertions(+), 1 deletions(-)
 delete mode 100644 fil
 create mode 100644 fila

Switched to branch 'master'

CONFLICT (rename/delete): Rename fil->fila in HEAD and deleted in new Automatic merge failed; fix conflicts and then commit the result.

asdjhaskd #### Still the master branch's content, `merge` apparently did nothing.

asdjhaskd

fatal: ambiguous argument ':3:fila': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

asjhdajkhsdkajhs ajksh askjdhaksdh kajshdk asd

Ramkumar Ramachandra venit, vidit, dixit 19.01.2010 08:22:

It's not a bug, it's a feature. Git does not track renames. It tracks content and detects renames when necessary. Knowing that it is easy to construct examples on which git merge "fails", such as the one you present.

A file which is changed completely is not a renamed file, it's a new one under the same name. Whether the committer meant to create a new file (using the same name by accident or on purpose) or whether it is really a heavily modified and renamed version - who knows? Git doesn't, and cannot, and it leaves that decision up to you.

If you really mean to modify and rename an existing file, then tell Git so:

git mv fil fila git commit -m 'we need a new name'

instead of your 'git rm fil' will record your intentions (not only for Git, but also for everyone else reading your log, such as you a year from now) and will make the merge succeed.

Michael

On Tue, 19 Jan 2010 13:07:28 +0000, Michael J Gruber wrote: ...

The intention would only be known informally in the commit message, as 'git mv' just removes the old and adds the new file, and still leave the work to the rename detection.

Indeed, changing
  >: git rm fil
  >: echo asjhdajkhsdkajhs >fila
  >: git add fila
to
  >: git mv fil fila
  >: echo asjhdajkhsdkajhs >fila
  >: git add fila
and even to
  >: git mv fil fila
  >: git cm 'other mv'
  >: echo asjhdajkhsdkajhs >fila
  >: git add fila
still gives the same rename/delete conflict because the rename
detection does not look at every single commit but only at
the total changes.

Which is actually good; when someone does

  cp prog.c prog.cpp
  git add prog.cpp && git commit
  vi prog.cpp --make-compile-again && git commit -a
  git rm prog.c && git commit

it is still seen as a rename prog.c->prog.cpp even though both existed in parallel for some commits.

Andreas

Right. Thanks for clearing that up for me.

Andreas Krey venit, vidit, dixit 19.01.2010 13:39:

Well, the solution I proposed (mv + commit rather than rm) certainly works for me, I tested it before. I have diff.renames=copies in my config but I don't think it should matter.

Michael