Make "terminator behavior" the default with --pretty=format: ?

4 messages, 3 authors, 2016-06-15 · open the first message on its own page

Make "terminator behavior" the default with --pretty=format: ?

From: Hrvoje Nikšić <hidden>
Date: 2016-06-15 22:50:37

Is there a reason, other than backward compatibility, for
"--prety=format:" to have separator rather than terminator semantics?

I got bitten by this badly today, because I was processing the output
of git log --pretty=format:... through sh, like this:

    git log --pretty=format:"%H %an" $old..$new | (
        while read commit author; do
           ... some processing ...
        done
    )

It turns out that the sh (which includes bash, dash, and zsh) "read"
built-in doesn't process lines that don't end in newline. The effect
was that the last line of output was silently ignored. It took some
hours to track down.

sh is not the only tool with this problem; many traditional Unix tools
don't process lines that don't end with newlines, and some require
special exceptions and kludges (think diff). Because of this I believe
"format:" should be changed to do terminator semantics, and tformat
deprecated. If this is not feasible, then the documentation should
recommend "tformat:", and only mention "format" as an afterthought,
rather than the other way around.

Re: Make "terminator behavior" the default with --pretty=format: ?

From: Will Palmer <hidden>
Date: 2016-06-15 22:50:37

On Tue, 2011-02-22 at 16:43 +0100, Hrvoje Nikšić wrote:
Is there a reason, other than backward compatibility, for
"--prety=format:" to have separator rather than terminator semantics?
The "default behaviour" is the behaviour which occurs when one /doesn't/
specify something. For example: --pretty="%H %an" uses terminator
semantics.

I agree that --pretty=sformat: might be less ambiguous, though.

Re: Make "terminator behavior" the default with --pretty=format: ?

From: Hrvoje Nikšić <hidden>
Date: 2016-06-15 22:50:37

On Tue, Feb 22, 2011 at 5:43 PM, Will Palmer [off-list ref] wrote:
On Tue, 2011-02-22 at 16:43 +0100, Hrvoje Nikšić wrote:
quoted
Is there a reason, other than backward compatibility, for
"--prety=format:" to have separator rather than terminator semantics?
The "default behaviour" is the behaviour which occurs when one /doesn't/
specify something. For example: --pretty="%H %an" uses terminator
semantics.
I didn't know that you could simply omit the "format:". Is it
documented anywhere? The docs say:

       --pretty[=<format>], --format[=<format>]
           Pretty-print the contents of the commit logs in a given
format, where <format> can be one of oneline, short,
           medium, full, fuller, email, raw and format:<string>. When
omitted, the format defaults to medium.

Re: Make "terminator behavior" the default with --pretty=format: ?

From: Jay Soffian <hidden>
Date: 2016-06-15 22:50:38

On Tue, Feb 22, 2011 at 11:51 AM, Hrvoje Nikšić [off-list ref] wrote:
On Tue, Feb 22, 2011 at 5:43 PM, Will Palmer [off-list ref] wrote:
quoted
On Tue, 2011-02-22 at 16:43 +0100, Hrvoje Nikšić wrote:
quoted
Is there a reason, other than backward compatibility, for
"--prety=format:" to have separator rather than terminator semantics?
The "default behaviour" is the behaviour which occurs when one /doesn't/
specify something. For example: --pretty="%H %an" uses terminator
semantics.
I didn't know that you could simply omit the "format:". Is it
documented anywhere? The docs say:

      --pretty[=<format>], --format[=<format>]
          Pretty-print the contents of the commit logs in a given
format, where <format> can be one of oneline, short,
          medium, full, fuller, email, raw and format:<string>. When
omitted, the format defaults to medium.
In the tformat section is:

 "In addition, any unrecognized string that has a % in it is
interpreted as if it has tformat: in front of it."

Of course, you need to know to read that far into the man page to find
that sentence, and the earlier summary of --pretty never gives any
hint to do so.

Mind submitting a documentation patch?

j.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help