Re: git-diff-tree rename detection bug

[Junio C Hamano <junkio@cox.net>]

Wayne Scott <wsc9tt@gmail.com> writes:

> Look at the diffs between ad6571a78ac74e9fa27e581834709067dba459af and
> it's parent with and without rename detection enabled.  (In linux-2.6
> git tree)

> $ git-diff-tree -r  -M $REV^1 $REV | grep termios.h
> :000000 100644 0000000000000000000000000000000000000000
>    237533bb0e9f1a3e640c4906d8b350deafd315b9 A      include/asm-powerpc/termios.h
> :100644 000000 97c6287a6cbaa5903ee1a5934a5553e9e485d8e7
>    0000000000000000000000000000000000000000 D      include/asm-ppc/termios.h
>
> Notice how the the fact that include/asm-ppc64/termios.h is deleted gets lost?
> Looks broken to me.

It looks broken to me, too.  I rebuilt from a reasonably ancient
source (v0.99) and re-run the test but I could not get it to
produce 'A' for include/asm-powerpc/termios.h.  So I rewound it
further to 4d235c8044a638108b67e22f94b2876657130fc8 commit,
which is really ancient version, but it still says it is renamed
from asm-ppc64 directory.  FWIW, all the v0.99* tagged versions
seem to detect that rename correctly and not lose anything in my
tests.

Which version of git do you run and on what platform?  It might
be that something in the diffcore chain is broken in non-i386
and/or non-GNU/Linux and/or non-GCC environment.

Shoot, I thought it would be a good practice-case for me to use
'git bisect' in reverse to find the commit that fixed a bug ;-).
My copy of linux-2.6 repository for testing is fully packed so I
could not try the commit that introduced diffcore-rename.c, but
that is what I really wanted to try.