On Saturday 04 September 2010 01:32:52 Jonathan Nieder wrote:

Andreas Gruenbacher wrote:

quoted

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