Re: Branch merge bug

From: Andreas Krey <a.krey@gmx.de>
Date: Jan 19, 2010, 12:39 UTC
Message-ID: <20100119123915.GB28667@inner.home.ulmdo.de>
In-Reply-To: <4B55A080.7010705@drmicha.warpmail.net>

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

Show 8 quoted lines

> 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.

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