Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 2/4] log and rev-list: Fixed newline termination issues with --graph

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:27

Adam Simpkins [off-list ref] writes:
The old code took care of these cases for CMIT_FMT_ONELINE, but not for
CMIT_FMT_USERFORMAT.  For CMIT_FMT_USERFORMAT, show_log() left each
entry without a terminating newline.  The next call to show_log() would
then try to print an extra blank line between entries.
The log family traditionally defined LF (or NUL when -z is in effect) as
separator between each pair of entries, not as terminator after each
entry.

This was because it would make much more sense to use separator semantics
when "git log -2" and "git log -1" is asked for.  The former gives the
tip, separator (typically an extra LF), and the second, while the latter
just shows the tip.  Neither case give extra LF after the last entry.
This worked only because each entry were supposed to end with its own LF,
so separator literally "separated" each entry with an extra blank line.

ONELINE however is special cased, because it makes no sense to give an
extran blank line to separate each entry.  Compactness is the point of the
format.

Switching separator semantics to terminator semantics in USERFORMAT
unconditionally is a bit problematic, because the userformat can be used
to format multi-line entries and in that case you may want the usual
"extra blank to separate" semantics, but it often is used to define an
alternate oneline format, in which case you do want terminator semantics
instead.

I suspect that --pretty=format: (i.e. userformat) should have a way to
explicitly tell which is wanted.  Perhaps we can keep the separator
semantics not to break existing users, and introduce a dummy expand item
(say, '%_') and when it appears in the pattern it would ask for the
terminator semantics instead?

In any case, I'm happy to see that somebody started looking into this, as
this "separator vs terminator" issue in userformat has been nagging me for
quite a while.  It might be good idea to have the change independently
from the graph extension first and then build the graph stuff on top of
the solidified base.  I dunno...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help