[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-patch] [BUG?] rename patch accepted with --dry-run, rejected wi

From: Andreas Gruenbacher
Subject: Re: [bug-patch] [BUG?] rename patch accepted with --dry-run, rejected without (Re: [PATCH V3] arm & sh: factorised duplicated clkdev.c)
Date: Sat, 4 Sep 2010 23:57:34 +0200
User-agent: KMail/1.12.4 (Linux/; KDE/4.3.5; i686; ; )

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]