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.