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

LT> ... But the thing is, LT> that's actually what I _want_, because I was planning on writing a tool LT> that applies patches that applies them all-or-nothing.

I was going through past messages and realized I missed this part of your message. Now I think I understand what git-apply program is all about.

There is one thing [*1*] currently missing from diff-patch output for your plan to fully work.

A type change, like a file turning into a symlink, is currently something built-in diff punts. Your earlier response to "What about modified and type changed" question suggests that you would want it to be expressed as a delete and a create, so I imagine that the "diff --git" output for this diff-raw:

    :100644 120000 abcdef... abcdef... T	frotz	frotz

you would want to see output as this:

    diff --git a/frotz b/frotz
    deleted file mode 100644
    --- frotz
    +++ /dev/null
    @@ -1 +0,0 @@
    -rezrov
    \ No newline at end of file
    diff --git a/frotz b/frotz
    new file mode 120000
    --- /dev/null
    +++ frotz
    @@ -0,0 +1 @@
    +rezrov
    \ No newline at end of file

Even simpler for me is not to do this "splitting a filepair into create and delete", and have diff compare the two blobs directly, though that would make a patch that does not make sense to humans:

    diff --git a/frotz b/frotz
    old mode 100644
    new mode 120000
    ... diff between readlink and file contents if any ...

A tree turning into a file and vice versa is something you are already taking care of in diff-tree when feeding the diffcore, and diff-cache and diff-files do not even see tree objects to begin with, so tree-to-file is something that will never be fed to the output routine as a matched filepair, and you will always get a delete/create pair with the current code. I am fairly certain, therefore, tree-to-file is not a problem. Only symlink vs file case is problematic with the current output routine.

[Footnote]

*1* Strictly speaking, there is another. Changes in tree object are not shown, either. This however will not be a problem for git-apply, because as long as the files underneath are handled correctly you will end up with the right tree.