Junio C Hamano <junkio@xxxxxxx> writes:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html