Re: [PATCH v3 3/3] ref-filter: use pretty.c logic for trailers

[Junio C Hamano <gitster@pobox.com>]

Hariom verma <hariom18599@gmail.com> writes:

> As per my understanding it works something like this:
>
> print a ref item... put newline... print a ref item... put newline..
> print a ref item... put newline... (so on)
>
> But the catch is that trailer comes with a newline already included.
> So it becomes:
>
> print trailers with newline included... put newline... print trailers
> with newline included... put newline.. (so on)

We know how it happens.  The question is if that is a sensible
behaviour, and if the trailing blank line was _intended_, or a bug
that nobody has complained about so far.

> we just can't directly remove the newline.

If we agree that the current behaviour is *not* sensible, then we
can.  On the "log --pretty" side, we have "terminator semantics" and
"separator semantics" between "tformat" and "format", when showing
more than one commits in a row, the "terminator semantics" places
one blank line after each commit we emit, while the "separator
semantics" gives one blank line between each commit pair.  I think
we initially (incorrectly) used terminator semantics and our output
for two commits looked like "CommitA <blank> CommitB <blank>" before
we fixed it to use separator semantics to show "CommitA <blank> CommitB"
without the useless trailing blank line.  We can apply the same principle
when "fixing" this issue to show a block of trailer lines (that is, the
change in behaviour to remove the trailing blank line turns out to
be a "fix").