From: Junio C Hamano Date: Thu, 26 May 2005 00:55:51 GMT Subject: Re: [PATCH] Make sure diff-helper can tell rename/copy in the new diff-raw format. Message-ID: <7v7jhmhkko.fsf@assigned-by-dhcp.cox.net> In-Reply-To: >>>>> "LT" == Linus Torvalds 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.