Re: [PATCH v3 3/3] ref-filter: use pretty.c logic for trailers
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 7, 2021, 20:09 UTC
- Message-ID
- <xmqqlfbz7i7i.fsf@gitster.c.googlers.com>
- In-Reply-To
- <CA+CkUQ9kHhbDVMru=pRO90o+k7cc_ykxN9JRFGMvoG3hkeGJpA@mail.gmail.com>
Hariom verma <hariom18599@gmail.com> writes:
Show 10 quoted lines
> 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").