Michał Kiedrowicz <michal.kiedrowicz@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> wrote: > ... >> 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. -- 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