From: Andreas Ericsson <exon@op5•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: "Michał Kiedrowicz" <michal.kiedrowicz@gmail•com>, git@vger•kernel.org
Subject: Re: [PATCH] builtin-apply: keep information about files to be deleted
Date: Sat, 18 Apr 2009 13:27:11 +0200 [thread overview]
Message-ID: <49E9B90F.8070204@op5.com> (raw)
In-Reply-To: <7vskk6y2tl.fsf@gitster.siamese.dyndns.org>
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
next prev parent reply other threads:[~2009-04-18 11:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-11 19:31 [PATCH] builtin-apply: keep information about files to be deleted Michał Kiedrowicz
2009-04-13 13:51 ` Michał Kiedrowicz
2009-04-13 18:51 ` Junio C Hamano
2009-04-13 21:03 ` Michał Kiedrowicz
2009-04-13 21:30 ` Junio C Hamano
2009-04-17 17:23 ` Michał Kiedrowicz
2009-04-18 4:59 ` Junio C Hamano
2009-04-18 11:27 ` Andreas Ericsson [this message]
2009-04-18 19:56 ` Junio C Hamano
2009-04-18 20:58 ` Michał Kiedrowicz
2009-04-18 21:03 ` [PATCH] tests: make test-apply-criss-cross-rename more robust Michał Kiedrowicz
2009-04-18 22:05 ` [PATCH] builtin-apply: keep information about files to be deleted Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E9B90F.8070204@op5.com \
--to=exon@op5$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=michal.kiedrowicz@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox