On Sat, 5 Jan 2008, Jakub Narebski wrote: > > Shouldn't the last block read for the modern git read: > > ------------------------------------------------ > :100644 000000 bcd1234... 0123456... M99 file0 > ------------------------------------------------ > > or is it only for '-B' togehter with '-M' or '-C'? Without -M/C, git re-joins them, so yeah, either the documentation (or that re-joining logic) is wrong. > Second: do you have per chance good examples of broken (and perhaps > merged together) pair, such that it is affected by --diff-filter=B; > with -B<num> or -B<num1>/<num2> parameters needed, if required. COPYING > and Makefile are one good example, but do you have literal files with > similar behavior? Hmm. A kernel example that shows *something* is git show -B --raw -r acbbbe9f5ab52da90a8edec02ec973e7f44dae81 which shows :100644 100644 eb14b18... 1f2d6d5... M093 include/asm-x86/byteorder.h even though that 093 is the *dissimilarity* index, so according to the documentation you quote you'd expect it to be :100644 000000 eb14b18... 0000000... D include/asm-x86/byteorder.h :000000 100644 0000000... 1f2d6d5... A include/asm-x86/byteorder.h instead of a M. Whether it's the docs or the behavior that should be changed, I dunno. Especially as using -B -M makes it all sane again, because then it shows it as the real rename: :100644 100644 435074a... 26b0dcd... M include/asm-x86/Kbuild :100644 100644 a45470a... 1f2d6d5... R061 include/asm-x86/byteorder_32.h include/asm-x86/byteorde :100644 000000 5e86c86... 0000000... D include/asm-x86/byteorder_64.h and it's all good. My personal opinion is that -B doesn't make much sense without M (or C), but at least you can see an example of the breaking behaviour in the kernel for a real case. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
