Re: Fix "git log -z" behaviour

From: Junio C Hamano <>
Date: 2007-02-10 18:32:10
Junio C Hamano <> writes:

> Linus Torvalds <> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at
Received on Sat Feb 10 18:36:15 2007

This archive was generated by hypermail 2.1.8 : 2007-02-10 18:37:47 EST