Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: [PATCH] builtin-apply: keep information about files to be deleted

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:46:36

Possibly related (same subject, not in this thread)

Michał Kiedrowicz [off-list ref] writes:
Junio C Hamano [off-list ref] wrote:
...
quoted
But if you have further patches that do the following (the "file
table" mechanism was added to handle concatenated patches that affect
the same path more than once), I thing PATH_TO_BE_DELETED logic would
break down:

     patch #3	renames alpha.c to hello.c
	patch #4	renames hello.c to alpha.c

When patch #3 is handled, the PATH_TO_BE_DELETED mark is long gone
from hello.c, and we will see the same failure you addressed in your
patch, won't we?
As far as I understand the code, diffs are applied independently
(for every file apply_patch() is called) and for every apply_patch()
call fn_table is cleared. So situation you described in only possible
in a *single* diff and I don't think it is possible to happen. 
Yes, one invocation of "git format-patch -1" will not produce such a
situation.

A single diff file that is concatenation of two "git format-patch -1"
output (or just a plain-old "diff -ru" output from outside git, perhaps
managed in quilt) was what introduced fn_table mechanism.  Apparently
people use "git apply" to apply such a patch.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help