On Saturday 04 September 2010 01:32:52 Jonathan Nieder wrote: > Andreas Gruenbacher wrote: > > > something pretty bizarre is going on here. The wget output modifies the same > > file twice, but both patches to this file have the same source sha1 (5645f35): > > From the git v1.6.0-rc0~92 changelog entry: > > apply: fix copy/rename breakage > > 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 times, by recording the postimage of patch > application of previous round and using it as the preimage for later > rounds. > > This "incremental" mode of patch application fundamentally contradicts > with the way git rename/copy patches are designed. When a git patch talks > about a file A getting modified, and a new file B created out of A, 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 in any way. This is explicitly done so for reviewability > of individual patches. > > With this commit, we do not look at 'fn_table' that records the postimage > of previous round when applying a patch to produce a new file out of an > existing file. Ouch ... this gets really messy when a user concatenates git style patches and they are not applied to exactly the same source tree. Thanks for digging out this commit message! Andreas -- 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