From: Junio C Hamano <junkio@cox.net>
Date: Sun, 22 May 2005 19:35:16 GMT
Subject: Re: [PATCH] The diff-raw format updates.
Message-ID: <7vy8a7cavf.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7v64xbdq4y.fsf@assigned-by-dhcp.cox.net>

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> The machine readable format has the same issue: it needs to be able to 
LT> distinguish between a "copy" (where the source remains) and a "rename" 
LT> (where the source is removed).

JCH> Why?  If the same path appears later as the left hand side then
JCH> it is a copy otherwise it is a rename.  Please see what
JCH> diffcore-rename does when assigning to dp->xfrm_msg.  

JCH> What I've been trying hard so far was to keep diff_filepair not
JCH> to be too specific to rename/copy.  What I do not like about
JCH> what is being proposed is that it would force me to introduce
JCH> this "is this a copy or a rename" flag to that structure.

Linus, another way of saying the above is this.

Think about the example in test that munge COPYING file.  What
was recorded in the two trees as the result of

    sed $munge_1 <COPYING >COPYING.1
    sed $munge_2 <COPYING COPYING.2
    rm COPYING

will be expressed as copy-edit of COPYING.1 and rename-edit of
COPYING.2 (both from COPYING).  But that is just _one_
interpretation diffcore-rename _arbitrarily_ makes.

It could have been copy-edit of COPYING.2 and rename-edit of
COPYING.1 (both from COPYING).  If you make the change you are
proposing to diff-raw format, reordering diff-raw entries stops
making sense, while the current format allows us to.  

It is similar to your argument of not _recording_ renames on
commit but _tracking_ it upon inspection.  I deliberatly chose
not to record rename/copy distinction in diff-raw --- it is to
be inferred from which entry touches the src _last_.  Everything
but the last one to touch the same path is copy, and the last
one is rename.