Re: [PATCH 0/3] Teach ref-filter API to correctly handle CRLF in messages

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

"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:

> The ref-filter API does not correctly handle commit or tag messages that use
> CRLF as the line terminator. Such messages can be created with the--verbatim 
> option of git commit and git tag, or by using git commit-tree directly.
>
> This impacts the output of git branch -v, and git branch, git tag and git
> for-each-ref when used with a --format argument containing the atoms 
> %(contents:subject) or %(contents:body).

What is missing from the above is the definition of "correct".
Without saying what you consider in the current behaviour is
"incorrect" and why, the first sentence does not give the right
information to readers.

Let me speculate why "such messages" are created by end users using
the --verbatim option.  They probably have unusual message that
needs to have whitespaces and characters that are stripped without
the option at the end of the lines in the message, and they
explicitly ask Git not to lose them with the option.  Perhaps CR may
be among those that they want to retain.

So "git for-each-ref --format='%(contents:body)'" should retain
these CRs and whitespaces at the end of these lines, but you are
reporting an incorrect behaviour, so perhaps somehow we lose them?

That does indeed sound like a bug.  We should keep them in the
output if the user took pains to deliberately place them in the
commit.  Unless the user tells us to clean/hide them with an option,
that is.

But as you did not say what your definition of correctness is in the
above two paragraphs, it is not clear to readers if that is the bug
you are trying to address, or even if such a bug exists in the first
place.

(haven't read the remainder of the cover or the patches yet).