Re: git apply vs. renamed files index mismatch

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 10, 2008, 03:31 UTC
Message-ID: <7v1vzs1xu2.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080909151446.GA10395@oksana.dev.rtsoft.ru>

Anton Vorontsov <avorontsov@ru.mvista.com> writes:

Show 12 quoted lines

> On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:
> ...
>> ...  It's an interesting idea from git person's point of
>> view (i.e. "would be fun to implement"), but I doubt it would be useful in
>> practice, because:
>> 
>>  (1) You often do not have the identically matching preimage;
>> 
>>  (2) More importantly, it is not unusual for people to *edit* the patch in
>>      their MUA (think of typofixes), after getting it out of git.
>
> Not for rename patches...

a. Why not?  Even if your patch is (totally uninteresting) pure rename, it
   is natural to review the patch before you send out, and it also is
   natural to get tempted to fix typoes, just for a straight normal patch.

b. If you can expect good behaviour out of people, by declaring "Not for
   rename patches" as your guarantee, what's the point of this discussion?

Show 7 quoted lines

> As for implementing, isn't this as simple as this pseudo code:
>
> if (index_deleted_file == index_new_file)
> 	if (deleted_file != new_file)
> 		printk("warning\n");
>
> In the git-apply?

Implementation is easy (I said "would be fun to code", didn't I? --- by the way, how did you match "index_deleted_file" with "index_new_file"?).

My point was that it would not be reliable enough to be useful in practice.