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

Junio C Hamano wrote:

Michał Kiedrowicz [off-list ref] writes:

quoted

... 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