"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
>
> Reftable precisely reproduces the given message. This leads to differences,
> because the files backend implicitly adds a trailing '\n' to all messages.
What does this mean? With the files backend we'll now see a
redundant two LFs in a row? I think you are careful enough not to
introduce unnecessary compatibility breakage like that, so perhaps
"implicitly adds" is a wrong way to characterize what happens in the
files backend, and it only adds LF when the message does not end
with one, but does not add an extra one if not necessary?
If so, then the change in the patch does not break compatibility,
but the above description does not give readers confidence that it
is indeed the case. IOW it is unclear how this change manages to
avoid breaking existing code.
Sorry, but I am left puzzled.
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
> ---
> builtin/checkout.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index af849c644f..bb11fcc4e9 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -884,8 +884,9 @@ static void update_refs_for_switch(const struct checkout_opts *opts,
>
> reflog_msg = getenv("GIT_REFLOG_ACTION");
> if (!reflog_msg)
> - strbuf_addf(&msg, "checkout: moving from %s to %s",
> - old_desc ? old_desc : "(invalid)", new_branch_info->name);
> + strbuf_addf(&msg, "checkout: moving from %s to %s\n",
> + old_desc ? old_desc : "(invalid)",
> + new_branch_info->name);
> else
> strbuf_insertstr(&msg, 0, reflog_msg);
