Re: [PATCH] Make sure diff-helper can tell rename/copy in the new diff-raw format.

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

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> Btw, I still disagree with this notion that the order of the
LT> use of the names makes a difference.

Having slept over it, I think I tend to agree.  I do not mind
annotating diff-raw output with "is this copy or is this rename"
bit anymore.  While we are at it, I would also want to either
(1) add similarity index field to diff-raw output, or (2) drop
similarity index output from the built-in patch output.  I am
inclined to vote for the former right now (if only it is more
fun to watch), but I can easily be dissuaded.

The proposed diff-raw format, in its fully expended form, is this:

in-place edit  :100644 100644 bcd1234... 0123456... file0 file0 . 0
copy-edit      :100644 100644 abcd123... 1234567... file1 file2 C 68
rename-edit    :100644 100644 abcd123... 1234567... file1 file3 R 86
create         :000000 100644 0000000... 1234567... file4 file4 . 0
delete         :100644 000000 1234567... 0000000... file5 file5 . 0
unmerged       :000000 000000 0000000... 0000000... file6 file6 . 0

The two columns added are rename/copy bit and similarity index.
When one->path and two->path are the same, they do not mean
anything but for parser simplicity's sake I'd like to have 0 in
the similarity index field and a dot in copy/rename bit field.

Human readable form should omit two->path and later fields
altogether if one->path == two->path, so the above becomes:

in-place edit  :100644 100644 bcd1234... 0123456... file0
copy-edit      :100644 100644 abcd123... 1234567... file1 file2 C 68
rename-edit    :100644 100644 abcd123... 1234567... file1 file3 R 86
create         :000000 100644 0000000... 1234567... file4
delete         :100644 000000 1234567... 0000000... file5
unmerged       :000000 000000 0000000... 0000000... file6

This has a nice property that diff-helper, aside from its
diff-raw parsing part, can become quite simplified.  It should
lose rename/copy related flags (-M, -C) because they are already
detected by the tool in the upstream of the pipe; and because
rename-copy is an asymmetric operation, it should also lose the
-R flag.  I think it already does a wrong thing when you use
diff-tree brothers with -M or -C and feed diff-helper -R with
the output that contains already matched rename/copy.

The only thing diff-helper _will_ continue to do is to take a
diff-raw output prepared by diff-tree brothers, and generate
what the upstream tool would have generated if it were given
'-p' (and that should have been the case from the beginning).  

Although I think diffcore transformers other than rename/copy
may still be useful (like pickaxe) in diff-helper, that also can
be handled upstream.