Junio C Hamano <junkio@xxxxxxx> writes:
> 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.
... well, it just occured to me that it might make sense not to
let this new "use NUL as inter-commit separator for grep -z"
semantics hijack existing -z option, but introduce another
option, say, -Z. Then you could even do something like:
git log -Z -r --numstat |
grep -z -e '^[1-9][0-9][0-9][0-9]* '
to find commits that has more than 100 lines of additions to a
file. (or use --stat and grep for '| *[1-9][0-9][0-9][0-9]* ' to
look for sum of addition+deletion ).
Hmmmm.
-
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