Re: [PATCH] The diff-raw format updates.

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.