Failed expectations or bug?

Hi,

I was learning about git rename detection and came across a unexpected result. See the following sequence:

$ mkdir /tmp/test-git
$ cd /tmp/test-git/
$ git init
Initialized empty Git repository in /private/tmp/test-git/.git/
$ git config diff.renames copies
$ echo a >> a
$ echo b >> a
$ echo c >> a
$ echo d >> a
$ git add a ; git commit -m 'added a'
Created initial commit a90001f: added a
  1 files changed, 4 insertions(+), 0 deletions(-)
  create mode 100644 a
$ git checkout -b t
Switched to a new branch "t"
$ git mv a b
$ git commit -m 'moved a to b'
Created commit 5f11e2f: moved a to b
  1 files changed, 0 insertions(+), 0 deletions(-)
  rename a => b (100%)
$ cp b c
$ git add c
$ git commit -m 'added c'
Created commit 8bf67c0: added c
  1 files changed, 4 insertions(+), 0 deletions(-)
  create mode 100644 c
$ git checkout master
Switched to branch "master"
$ perl -pi -e 's/d/D/' a
$ git add a
$ git commit -m 'd is now D'
Created commit c082684: d is now D
  1 files changed, 1 insertions(+), 1 deletions(-)
$ git merge t
Merge made by recursive.
  a => b|    2 +-
  a => c|    0
  2 files changed, 1 insertions(+), 1 deletions(-)
  copy a => b (75%)
  rename a => c (100%)
$ ls
b	c
$ cat b
a
b
c
d
$ cat c
a
b
c
D

Maybe I have the wrong expectations, but after the merge I was expecting either:

  * b and c have the same content, with the modified D;
  * b has the modifications made in master, and c has the original  
content.

I did not expect the patch to 'a' in master to propagate across the copy to c.

What am I doing wrong here?

Thanks,