Git development
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Simplify '--prett=xyz' options
Date: Sat, 15 Aug 2009 13:36:13 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0908151324380.3162@localhost.localdomain> (raw)
In-Reply-To: <7viqgoestz.fsf@alter.siamese.dyndns.org>



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

  reply	other threads:[~2009-08-15 20:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-15 19:01 Simplify '--prett=xyz' options Linus Torvalds
2009-08-15 19:19 ` Thomas Rast
2009-08-15 19:50   ` Linus Torvalds
2009-08-15 20:16     ` Junio C Hamano
2009-08-15 20:36       ` Linus Torvalds [this message]
2009-08-15 21:05         ` Avery Pennarun
2009-08-15 21:29           ` Linus Torvalds
2009-08-15 21:39     ` Linus Torvalds
2009-08-15 20:22 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.01.0908151324380.3162@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=trast@student.ethz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox