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 <redacted>
Date: Sat, 21 May 2005 13:36:25 -0700
Message-ID: [off-list ref]

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

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

quoted

Once we start to think of it this way, it becomes quite tempting
to change the diff-raw format to actually match the above
concept.

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.