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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 13, 2009, 21:30 UTC
Message-ID: <7v1vrwdyxx.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090413230351.7cbb01f5@gmail.com>

Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> 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.