Re: [PATCH] apply: fix copy/rename breakage

[Johannes Sixt <j.sixt@viscovery.net>]

Don Zickus schrieb:
> On Wed, Jul 09, 2008 at 08:10:58PM -0700, Junio C Hamano wrote:
>> However, this "incremental" mode of patch application contradicts with the
>> way git rename/copy patches are fundamentally designed.  When a git patch
>> talks about a file A getting modified, and a new file B created out of B,
>> like this:
>>
>> 	diff --git a/A b/A
>> 	--- a/A
>> 	+++ b/A
>> 	... change text X here ...
>> 	diff --git a/A b/B
>> 	copy from A
>> 	copy to B
>> 	--- a/A
>> 	+++ b/B
>> 	... change text Y here ...
>>
>> the second change to produce B does not depend on what is done to A with
>> the first change (this is explicitly done so for reviewability of
>> individual patches).
>>
>> With this patch, we disable the postimage record 'fn_table' when applying
>> a patch to produce new files out of existing file by copying to fix this
>> issue.
> 
> Odd.  I guess the way I read this workflow is
> 
> apply change X to A, copy A' to B, apply change Y to B => B' now has changes X+Y
> 
> But instead you are saying B' only has change Y because A is copied to B
> not A'.
> 
> Regardless, it doesn't affect my workflow.

Oh, it does. It's a normal git diff where a copy was detected!

Don't let you distract by the word "incremental" and by the names A and B.
In the example above, the change X comes first because 'A' is sorted
before 'B'. If the roles of A and B were swapped, then you have this patch:

 	diff --git a/A b/A
 	copy from B
 	copy to A
 	--- a/A
 	+++ b/A
 	... change text Y here ...
 	diff --git a/A b/B
 	--- a/A
 	+++ b/B
 	... change text X here ...

See?

-- Hannes