Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:58

quoted
quoted
quoted
quoted
"LT" == Linus Torvalds [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help