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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 9, 2020, 15:14 UTC
Message-ID: <xmqqimjd1rx2.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <pull.576.git.1583692184.gitgitgadget@gmail.com>

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

Show 7 quoted lines

> 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).