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

Jeff King [off-list ref] writes:

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 [off-list ref]
    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.