Linus Torvalds [off-list ref] writes:
On Sat, 15 Aug 2009, Thomas Rast wrote:
quoted
Granted, it makes it equivalent to --pretty=tformat:foo, but isn't
tformat the better choice in many cases?
Not really. Look at what happens with
git log --stat --pretty=format:%s
and then try tformat instead. 'tformat' is broken, as is our current
--format=%s.
In other words, all of that crud is totally illogical, and our "short
versions" (--oneline and --format=) were done entirely incorrectly (well,
--oneline probably has the _right_ semantics, and --pretty=oneline is just
wrong, but whatever).
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.
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
On Sat, Aug 15, 2009 at 4:36 PM, Linus
Torvalds[off-list ref] wrote:
On Sat, 15 Aug 2009, Junio C Hamano wrote:
quoted
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).
I'm guessing that "after header" was just an implementation error. It
was presumably intended to be "after commit", so that the only
difference between format and tformat is the presence or absence of
the very last terminator.
Maybe the correct fix is just to make tformat not broken?
Avery
On Sat, 15 Aug 2009, Avery Pennarun wrote:
I'm guessing that "after header" was just an implementation error. It
was presumably intended to be "after commit", so that the only
difference between format and tformat is the presence or absence of
the very last terminator.
Maybe the correct fix is just to make tformat not broken?
I do agree. 'tformat' is broken. But my point was more that 'tformat' was
introduced for all the wrong reasons (ie that 'format' was broken, and
then instead of fixing 'format', people introduced 'tformat' with a
_different_ brokenness).
Linus