From: Andreas Ericsson Date: Sat, 18 Apr 2009 11:27:11 GMT Subject: Re: [PATCH] builtin-apply: keep information about files to be deleted Message-ID: <49E9B90F.8070204@op5.com> In-Reply-To: <7vskk6y2tl.fsf@gitster.siamese.dyndns.org> Junio C Hamano wrote: > Michał Kiedrowicz 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