Re: Fix "git log -z" behaviour

From: Junio C Hamano <junkio@cox.net>
Date: Feb 10, 2007, 07:32 UTC
Message-ID: <7vtzxumps5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7v7iusz3c2.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 14 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> For the normal case where the termination character is '\n', this 
>> obviously doesn't change anything at all, since we just switched two 
>> identical characters around. So it's very safe - it doesn't change any 
>> normal usage, but it definitely fixes "git log -z".
>
> Gaah.
>
> I have already applied this but I think this has fallout for
> existing users of "-z --raw".  Nothing in-tree uses "git log" as
> the upstream of a pipe as far as I know because in-tree stuff
> tend to stick to plumbing when it comes to scripting, but I
> think your patch would affect the plumbing level as well.

I think the new semantics for -z ("inter-record termination is NUL") makes a lot more sense for "-p -z" format that shows commit log message and the patch text. It makes filtering the output with "grep -z" feel much more natural.

The new semantics is however quite inconsistent with the other formats: --raw, --name-only and --name-status. These already use NUL for separating pathnames and fields when -z is given, in order to allow scripts sensibly deal with pathname that contain funny characters (e.g. LF and HT). Nobody is likely to feed their output to "grep -z", but one problematic case I see is to use this:

	git log -z --raw -r --pretty=raw $commit

or its equivalent:

	git rev-list $commit |
        git diff-tree --stdin --raw -r --pretty=raw

to prepare data to feed something like fast-import.

But such newly written scripts can read from non -z and unwrap paths themselves just as easily (the pathname safety with NUL was invented before we started using c-quote consistently), so it might be Ok to leave them (slightly) broken.

So, I give up.