Re: [RFC/PATCH 2/2] fix missing NUL termination with pretty=tformat

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 1, 2009, 08:27 UTC
Message-ID: <7vprcklse5.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090701072632.GB8101@sigio.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> This one is RFC. It is missing tests, but that is because I am not
> completely sure what we want the output to look like. With this change,
> you still get a newline at the end of a single-line user-formatted
> string, like:
>
>   $ git log -z --format:%s
>   three
>   ^@two
>   ^@one
>   ^@

I haven't thought things through, but my knee-jerk reaction is that we should treat "%s" itself as not having a final LF in itself. So I would actually expect the above to produce

    three^@two^@one^@

In other words, --pretty=format:%s and --pretty=format:X-%s-Y should behave identically. Strings produced by these format specifications will not have terminating LF appended (because %s itself does not end with LF, and in the second example you did not write any LF after your "Y"). For consistency, I think %b should include the LF at the end on its own, but I may be wrong on this last point.

"git log" (with or without -z) would begin with the string that comes out of the log message part (i.e. with or without any custom format via format/tformat) first.

When run with -p, the output would be followed by a LF (with -z, or without), followed by the patch text (each line of which is terminated with a LF, again with or without -z). Without -p, this part is omitted.

After that, a LF/NUL (depending on the use of -z) would be appended if there are more records or if we are using the terminator semantics. Then we would move on to the next record.

E.g.  When "log -p" shows a commit with a one-liner message, like this:

    commit e8a39af8d471d190a749c390a0cf614cb59ec8ee
    Author: Junio C Hamano <gitster@pobox.com>
    Date:   Wed Jul 1 00:50:48 2009 -0700

        second commit

    diff --git a/one b/one
    index e69de29..d00491f 100644
    --- a/one
    +++ b/one
    @@ -0,0 +1 @@
    +1

    Side note. Conceptually I would say that canned formats (--pretty,
    --pretty=short etc. but not --pretty=oneline) produce a string that
    ends with "second commit\n" in the above example, and the blank line
    between the log and beginning of "diff --git" is coming from the rule
    "log is always followed by a LF (with or without -z)".

"log -p --pretty=format:X-%s-Y" would begin with

    X-second commit-Y
    diff --git a/one b/one
    index e69de29..d00491f 100644

"log --pretty=format:X-%s-Y" would become

    X-second commit-Y
    X-initial commit-Y

and with -z, the latter would look
    
    X-second commit-Y^@X-initial commit-Y

while "log --pretty=tformat:X-%s-Y -z" would be

    X-second commit-Y^@X-initial commit-Y^@

All of the above was written, ignoring the memory of what the current code actually does, nor checking if it is easy to implement without tweaking the current code structure too much. So it may not help your RFC, but I at least think it is internally consistent.