Re: updated design for the diff-raw format.

(third of the replayed messages)

To: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 3/3] Diff overhaul, adding the other half of copy
 detection.
From: Junio C Hamano <junkio@cox.net>
Date: Sat, 21 May 2005 13:36:25 -0700
Message-ID: <7vfywggvue.fsf@assigned-by-dhcp.cox.net>

LT> On Sat, 21 May 2005, Junio C Hamano wrote:

LT> I agree, and I was going to suggest changing the "raw" diff output for all LT> the same reasons. So I think you should do it, as the old format was based LT> on not really knowing where this all would take us. I think your proposed LT> format is visually nicer, and it's obviously more flexible.

LT> Small suggestion on termination of the thing: LT> - add a "inter_name_termination" variable, which defaults to '\t' (the LT> same way "line_termination" defaults to '\n') LT> - make "-z" set both "inter_name_termination" _and_ "line_termination" to LT> 0. LT> - make the spacing be fixed (and add a test for it, so that there is LT> never any confusion): regular spaces between the non-file-names, and LT> "inter_name_termination" before the filenames, and "line_termination" LT> after the second filename.

I am debating myself if I wanted to add this to the above list:

     - omit the inter_name_termination and second path if both
       paths are the same, only when doing human-readable
       (i.e. inter_name_termination != line_termination).

I'm not going to do this immediately though, for two reasons.

Somehow I failed to CC the GIT list the message you are responding to. Discussing a change with an impact of this scale needs to be taken public before going further, so with your permission I would like to repost both my original ("Once we start to think of it this way...") and your response to the GIT list first. At least I feel that Petr needs to be in the loop about this one.

Another reason is that, as I said, I still have problems about the diffcore interface, namely the lack of interface for the applications to ask diffcore what the final outcome is. The "diff-tree not being to omit its header output when pickaxe says the result is empty" problem is primarily what bothers me, but I think we want a more generic interface for the application to inspect the result (not just emptiness check), probably before starting to feed the resulting diff list to the external diff.

Note that this interface needs to be inspection only---if the application wants to further manipulate the result, then we should extend list of diffcore transformations called from diff_flush(). Which takes me to another point --- maybe the list of diffcore transformations called from diff_flush() should be made stackable, like streams.