git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Luca Weiss <luca@z3ntu.xyz>
To: phillip.wood@dunelm.org.uk, Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Luca Weiss via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Denton Liu <liu.denton@gmail.com>
Subject: Re: [PATCH 2/2] merge: make sure to terminate message with newline
Date: Wed, 21 Jul 2021 12:41:44 +0200	[thread overview]
Message-ID: <7464462.Hysq1jLez0@g550jk> (raw)
In-Reply-To: <YPMXqLESKApq2uPI@coredump.intra.peff.net>

On Samstag, 17. Juli 2021 19:47:20 CEST Jeff King wrote:
> 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

Hi Peff,

if you have a good idea on how to create these patches, feel free to do so.
If not, I can take a shot at it this or next week.

Regards
Luca



  reply	other threads:[~2021-07-21 11:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16  7:43 [PATCH 0/2] Normalize newlines in merge & interpret-trailer Luca Weiss via GitGitGadget
2021-07-16  7:43 ` [PATCH 1/2] trailer: handle input without trailing newline Luca Weiss via GitGitGadget
2021-07-16 19:35   ` Jeff King
2021-07-16  7:43 ` [PATCH 2/2] merge: make sure to terminate message with newline Luca Weiss via GitGitGadget
2021-07-16 10:23   ` Phillip Wood
2021-07-16 12:37     ` Luca Weiss
2021-07-16 17:30       ` Phillip Wood
2021-07-16 19:33         ` Jeff King
2021-07-16 20:34           ` Junio C Hamano
2021-07-16 21:10             ` Jeff King
2021-07-16 22:13               ` Junio C Hamano
2021-07-17 13:40               ` Phillip Wood
2021-07-17 17:47                 ` Jeff King
2021-07-21 10:41                   ` Luca Weiss [this message]
2021-08-26 18:32                   ` Luca Weiss
2021-07-16 20:20   ` Junio C Hamano
2021-07-16 22:10 ` [PATCH 0/2] Normalize newlines in merge & interpret-trailer Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7464462.Hysq1jLez0@g550jk \
    --to=luca@z3ntu.xyz \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).