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

[Andreas Ericsson <exon@op5.com>]

Junio C Hamano wrote:
> Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> 
>> ... However, there are some cases when these two
>> rules may cause problems:
>>
>> patch #1: rename A to B
>> patch #2: rename C to A
>> patch #3: modify A
>>
>> Should patch #3 modify B (which was A) or A (which was C)?
>>
>> patch #1: rename A to B
>> patch #2: rename B to A
>> patch #3: modify A
>> patch #4: modify B
>>
>> Which files should be patched by #3 and #4?
>>
>> In my opinion both #3 and #4 should fail (or both should succeed) --
>> with my patch only #3 will work and #4 will be rejected, because in #2
>> B was marked as deleted.
> 
> Both of the examples above cannot be emitted as a single commit by
> format-patch; the user is feeding a combined patch.  Perhaps renames
> in each example sequence were came from one git commit but modifications
> are from separate commit or handcrafted "follow-up" patch.
> 
> There are two stances we can take:
> 
>  (1) The user knows what he is doing.
> 
>      In the first example, if he wanted the change in #3 to end up in B,
>      he would have arranged the patches in a different order, namely, 3 1
>      2, but he didn't.  We should modify A (that came from C).
> 

This gets my vote. Standard "diff -u" patches have always had to be
numbered properly if they have even the slightest chance of interfering
with each other, so developers are already used to it.

/Andreas