From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 48DB31F5AE for ; Sat, 17 Jul 2021 17:47:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233429AbhGQRuT (ORCPT ); Sat, 17 Jul 2021 13:50:19 -0400 Received: from cloud.peff.net ([104.130.231.41]:52854 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231253AbhGQRuS (ORCPT ); Sat, 17 Jul 2021 13:50:18 -0400 Received: (qmail 24420 invoked by uid 109); 17 Jul 2021 17:47:21 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sat, 17 Jul 2021 17:47:21 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 19748 invoked by uid 111); 17 Jul 2021 17:47:21 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 17 Jul 2021 13:47:21 -0400 Authentication-Results: peff.net; auth=none Date: Sat, 17 Jul 2021 13:47:20 -0400 From: Jeff King To: phillip.wood@dunelm.org.uk Cc: Junio C Hamano , Luca Weiss , Luca Weiss via GitGitGadget , git@vger.kernel.org, Denton Liu Subject: Re: [PATCH 2/2] merge: make sure to terminate message with newline Message-ID: References: <31371c25743e1001b4fac89e80e7206ff477ac8a.1626421416.git.gitgitgadget@gmail.com> <8678772b-dd5d-9188-8b63-98d05cedb323@gmail.com> <16229b1d-e4a6-7a8d-8ea0-ae7c3f13075d@gmail.com> <693954a7-af64-67c5-41b9-b648a9fe3ef2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <693954a7-af64-67c5-41b9-b648a9fe3ef2@gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sat, Jul 17, 2021 at 02:40:55PM +0100, Phillip Wood wrote: > > which would cover that case. But Phillip mentioned that our own > > fmt_merge_msg() does not include a newline. > > I mentioned that we remove the newline that is added by fmt_merge_msg(), not > that there is no newline added by fmt_merge_msg() - maybe I wasn't clear > enough. In builtin/merge.c:prepare_merge_message() we do > > fmt_merge_msg(merge_names, merge_msg, &opts); > if (merge_msg->len) > strbuf_setlen(merge_msg, merge_msg->len - 1); Of maybe I didn't read carefully enough. :) Either way, thanks for clarifying. Doing something like: cat >.git/hooks/commit-msg <<\EOF #!/bin/sh xxd "$1" EOF chmod +x .git/hooks/commit-msg git merge --no-edit ... shows off the problem; the hook sees that intermediate state. Likewise if we do: git merge -m "foo" ... which similarly suppresses the editor. There are actually two interesting cases here: - if merge.log is not set, then we'd see "foo" with no newline - if it is set, we'll get a newline after "foo", but with no newline after the log data Likewise for: printf foo >no-newline git merge -F no-newline ... So I think we'd probably want to see a 3-patch series: 1. Make interpret-trailers handle input missing the final newline. This isn't strictly necessary after patches 2 and 3, but it makes sense to be more robust with unexpected input. 2. Drop the newline-stripping from prepare_merge_message(). The examples above show some ways we could cover this in the tests. This will help --no-edit case, but also using merge.log with "-m" or "-F". 3. Teach prepare_to_commit() to add the extra newline before letting hooks see the message. This should probably be done only when cleanup_mode != COMMIT_MSG_CLEANUP_NONE. Luca, do you want to try revising your series in that direction? -Peff