Don Zickus schrieb: > On Wed, Jul 09, 2008 at 08:10:58PM -0700, Junio C Hamano wrote: >> 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 X here ... >> diff --git a/A b/B >> copy from A >> copy to B >> --- a/A >> +++ b/B >> ... change text Y 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. Oh, it does. It's a normal git diff where a copy was detected! Don't let you distract by the word "incremental" and by the names A and B. In the example above, the change X comes first because 'A' is sorted before 'B'. If the roles of A and B were swapped, then you have this patch: diff --git a/A b/A copy from B copy to A --- a/A +++ b/A ... change text Y here ... diff --git a/A b/B --- a/A +++ b/B ... change text X here ... See? -- Hannes -- 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
