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> ... 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.