Re: Fix "git log -z" behaviour

>
> For commit messages, we should really put the "line_termination" when we
> output the character in between different commits, *not* between the
> commit and the diff. The diff goes hand-in-hand with the commit, it
> shouldn't be separated from it with the termination character.
>
> So this:
>  - uses the termination character for true inter-commit spacing
>  - uses a regular newline between the commit log and the diff
>
> We had it the other way around.
>
> 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".
>
> By fixing "git log -z", you can now also do insane things like
>
>         git log -p -z |
>                 grep -z "some patch expression" |
>                 tr '\0' '\n' |
>                 less -S
>
> and you will see only those commits that have the "some patch expression"
> in their commit message _or_ their patches.
>
> (This is slightly different from 'git log -S"some patch expression"',
> since the latter requires the expression to literally *change* in the
> patch, while the "git log -p -z | grep .." approach will see it if it's
> just an unchanged _part_ of the patch context)
>
> Of course, if you actually do something like the above, you're probably
> insane, but hey, it works!
>
> Try the above command line for a demonstration (of course, you need to
> change the "some patch expression" to be something relevant). The old
> behaviour of "git log -p -z" was useless (and got things completely wrong
> for log entries without patches).
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>
> On Wed, 7 Feb 2007, Linus Torvalds wrote:
> >
> > Also, I just checked, and we have a bug. Merges do not have the ending
> > zero in "git log -z" output. It seems to be connected to the fact that we
> > handle the "always_show_header" commits differently (the ones that we
> > wouldn't normally show because they have no diffs associated with them).
> >
> > The obvious fix for that failed. I'll look at it some more.
>
> Actually, the obvious fix was right, I just did the *wrong* obvious fix at
> first ;)