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

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.