Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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...
Some alternatives to specify terminator semantics I considered are:
(1) Presence of %_ in "--pretty=format:..." triggers terminator
semantics and %_ itself interpolates an empty string; otherwise
separator semantics is used.
(2) Presence of %n in "--pretty=format:..." means a multi-line output and
uses separator as before; lack of %n means it is a one-line format
and uses terminator.
(3) A new option --pretty=tformat:... (i.e. tformat instead of format)
means LF (or NUL) is used as terminator instead of separator;
(4) A new syntax --pretty=format/... (i.e. slash instead of the usual
colon) means LF (or NUL) is used as terminator instead of separator;
The first one is what I suggested in the message, but it feels somewhat
hacky. I suspect that the second one would catch 99% of the cases, but it
is DWIM and it is known that DWIM can go wrong. I favor design along
the lines of (3) or (4), which I think would be much cleaner.
I however do not particularly like either "tformat" which is a non-word,
nor ":" vs "/" whose differences do not intuitively translate to
"separator vs terminator" distinction.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
