Re: Antw: Re: blank lines in pre-created merge message

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 31, 2019, 13:00 UTC
Message-ID: <nycvar.QRO.7.76.6.1907311448280.21907@tvgsbejvaqbjf.bet>
In-Reply-To: <5D3FE919020000A100032932@gwsmtp.uni-regensburg.de>

Hi Ulrich,

On Tue, 30 Jul 2019, Ulrich Windl wrote:

Show 37 quoted lines

> >>> Johannes Schindelin <Johannes.Schindelin@gmx.de> schrieb am
> >>> 25.07.2019 um 13:58 in Nachricht
> >>> <nycvar.QRO.7.76.6.1907251355500.21907@tvgsbejvaqbjf.bet>:
> >
> > On Thu, 25 Jul 2019, Ulrich Windl wrote:
> >
> >> >>> Johannes Schindelin <Johannes.Schindelin@gmx.de> schrieb am
> >> >>> 25.07.2019 um 12:07 in Nachricht
> >> >>> <nycvar.QRO.7.76.6.1907251204310.21907@tvgsbejvaqbjf.bet>:
> >> >
> >> > On Wed, 24 Jul 2019, Ulrich Windl wrote:
> >> >
> >> >> When using "git merge ‑‑no‑ff ‑‑no‑commit ..", the pre‑created
> >> >> merge message always contains two empty lines in between the
> >> >> comment lines. However if there was a merge conflict (being
> >> >> resolved) an extra blank line is added after the fiVrst line.
> >>
> >> [...]
> >
> >> Could anybody provide a rough overview how and where these editor
> >> comments are created?
> >
> > The best bet would be to call `git grep` with text in that pre‑created
> > merge message, preferably some text that is most likely fixed, i.e. that
> > does not depend on the current worktree/commit.
> >
> > If you give me an example of such a merge message, I can provide you
> > with the appropriate `git grep` call and the code locations to touch.
>
> Hi!
>
> Sorry for the delay:
> OK, here is an example where the auto-generated comment has two blank lines:
> ---snip---
> Merge branch 'shared'
> #
> # It looks like you may be committing a merge.

The command-line I used was:

	git grep "It looks like you may be committing a merge"

It points you to https://github.com/git/git/blob/v2.22.0/builtin/commit.c#L827

As you can easily see, that message does end in a `\n`, (and also in the other conditional arm, for cherry-pick), and it is printed via `status_printf_ln()` (the `_ln` means that it adds another newline), and in addition another newline is printed directly after that if block:

		fprintf(s->fp, "\n");

Since this extra empty line is bothering you, how about giving it a try to fix it yourself? I guess the best bet is to delete the `_ln` from the function call, as it avoids changing a message that was already translated into about a dozen languages (and would have to be translated again if you changed it, even if only to remove a trailing newline).

If this works for you, please follow https://github.com/git/git/blob/v2.22.0/Documentation/SubmittingPatches to contribute the patch to the Git mailing list.

Ciao, Johannes

Show 23 quoted lines

> # If this is not correct, please remove the file
> #       .git/MERGE_HEAD
> # and try again.
>
>
> # Please enter the commit message for your changes. Lines starting
> # with '#' will be ignored, and an empty message aborts the commit.
> # On branch master
> # All conflicts fixed but you are still merging.
> #
> # Changes to be committed:
> #       new file:   .filelist
> #       new file:   .gitignore
> ...more lines omitted
> ---snip---
>
> >
> > Ciao,
> > Johannes
>
>
>
>