Re: [PATCH] diff-raw format update take #2.

From: Junio C Hamano <junkio@cox.net>
Date: May 24, 2005, 00:45 UTC
Message-ID: <7v64x91mfb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <046ec1d00820537103092ed264f81f65.IBX@taniwha.stupidest.org>

>>>>> "CW" == Chris Wedgwood <cw@f00f.org> writes:

CW> On Mon, May 23, 2005 at 05:25:32PM -0700, Junio C Hamano wrote:

>> Then you would use '-z'.  (10) becomes NUL which your path
>> cannot have inside.  So do (12) and (14).

CW> Sure, I guess I meant to what would happen when not using '-z'? Will CW> something notice this early on barf and tell me to use '-z' or will CW> BadThings(tm) just come bite me at some (possibly) later stage?

Embedded spaces in path is _always_ safe. And I think with the current code unless you are using rename detection, your path with embedded TABs are also OK (but do not depend on it).

If you are using rename detetion, your rename source path is truncated at the first TAB and your rename destination path has the remainder of the source path, with an extra TAB, prepended to it. Nothing as far as I know would detect and warn that situation. If you have an embedded LF, then you are SOL, period. Just do not do it.

I _could_ add a code to diff-helper to barf if your path have an embedded TAB in it, but I am not sure if that is worth it. Also I _could_ add a code to diff-raw output routine to barf if your path have these problematic characters in it and you are not using '-z'. I think the latter makes quite a lot of sense.

The design comes from this reasoning (third point of "a few results"); please look in your archive if you care about the details.

    To:	git@vger.kernel.org
    Subject: Re: updated design for the diff-raw format.
    Date:	Sat, 21 May 2005 16:17:33 -0700
    Message-ID: <7vll68dv8y.fsf@assigned-by-dhcp.cox.net>

    (second of the replayed message, with blessing from Linus)