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

[Don Zickus <dzickus@redhat.com>]

On Wed, Jul 09, 2008 at 08:10:58PM -0700, Junio C Hamano wrote:
> Recently, 7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught
> "git-apply" to grok a (non-git) patch that is a concatenation of separate
> patches that touch the same file number of files, by recording the
> postimage of patch application of previous round and using it as the
> preimage for later rounds.
> 
> 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 here ...
> 	diff --git a/A b/B
> 	copy from A
> 	copy to B
> 	--- a/A
> 	+++ b/B
> 	... change text 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.

ACK.

Cheers,
Don