[bug-patch] [BUG?] rename patch accepted with --dry-run, rejected without (Re: [PATCH V3] arm & sh: factorised duplicated clkdev.c)
Andreas Gruenbacher
agruen at suse.de
Sat Sep 4 17:57:34 EDT 2010
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
More information about the linux-arm-kernel
mailing list