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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
