Re: Fix "git log -z" behaviour

> Junio C Hamano <junkio@cox.net> writes:
>
>> 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.