Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

Re: Simplify '--prett=xyz' options

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:47:15


On Sat, 15 Aug 2009, Junio C Hamano wrote:
If you try that without --stat, i.e.

    $ git log -4 --pretty=format:%s | cat -e
    $ git log -4 --pretty=tformat:%s | cat -e

I suspect you may then find that --pretty=format (not --pretty=tformat) is
broken.
I disagree. The real brokenness is that we don't have any way to say "I 
want no newline at all after the format", and then having this mixup with 
the whole "terminator" thing - sometimes it's "between commits" (which is 
_correct_ any time you have stat info or something), and sometimes it's 
"after header" (which is almost always incorrect).

For an example of this, try to do a one-line format that shows the 
diffstat on the same line. IOW, what you really want is something like

	git log -4 --shortstat --format=%s%NOTERM

but you can't do it at all right now - and defaulting to the "tformat" 
thing is actually _worse_.

So I do agree that "format" is broken and confused. I just think that 
"tformat" is EVEN MORE broken and confused, it just happens to fix that 
one form of brokenness that "format" has.

Notice how "CMIT_FMT_ONELINE" use the "use_terminator" (like tformat), but 
then does things right (unlike tformat). In particular, it's this one:

        pp_header(fmt, abbrev, dmode, encoding, commit, &msg, sb);
        if (fmt != CMIT_FMT_ONELINE && !subject) {
                strbuf_addch(sb, '\n');
        }       
	..
        /* Make sure there is an EOLN for the non-oneline case */
        if (fmt != CMIT_FMT_ONELINE)
                strbuf_addch(sb, '\n');

and notice how we have no way to edit those from the "format" descriptors.

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