blank lines in pre-created merge message

blank lines in pre-created merge message

[Ulrich Windl]

Hi!

I think I had tried bringing this to your attention before, but I think it was
without success.
The issue may seem purely cosmetical, while being easy to fix (is my guess):

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
first line.

In vi those empty lines are easy to spot, and I routinely remove them. But
maybe it's better not to create them at the beginning. (A "normal commit" never
creates any emüpty lines in the pre-created comment)

My Git version is 2.12.3, but the bug is probably quite old...

Regards,
Ulrich Windl

Re: blank lines in pre-created merge message

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

Hi Ulrich,

On Wed, 24 Jul 2019, Ulrich Windl wrote:

> I think I had tried bringing this to your attention before, but I think it was
> without success.
> The issue may seem purely cosmetical, while being easy to fix (is my guess):
>
> 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
> first line.
>
> In vi those empty lines are easy to spot, and I routinely remove them. But
> maybe it's better not to create them at the beginning. (A "normal commit" never
> creates any emüpty lines in the pre-created comment)

I could imagine that
https://github.com/gitgitgadget/git/commit/b2f5171ecc2feb4192acd80f5a6b05c06e099e97
addresses that. Would be good if you could try; just build `pu` from
https://github.com/git/git (`make install` will install it into your
`$HOME/bin` and you can test that easily).

If not, how about giving it a try to fix it yourself? This is open
source, giving you great power to change the entire source code in your
local repository as you wish. And of course, with great power... comes
great responsibility.

> My Git version is 2.12.3, but the bug is probably quite old...

You might think that the bug is probably quite old, but what is really
old is your Git version. The current one is v2.22.0.

First order of business should be to verify that it has not been fixed
in the meantime ;-)

Ciao,
Johannes

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

[Ulrich Windl]

>>> 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>:
> Hi Ulrich,
> 
> On Wed, 24 Jul 2019, Ulrich Windl wrote:
> 
>> I think I had tried bringing this to your attention before, but I think it

> was
>> without success.
>> The issue may seem purely cosmetical, while being easy to fix (is my
guess):
>>
>> 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
>> first line.
>>
>> In vi those empty lines are easy to spot, and I routinely remove them. But
>> maybe it's better not to create them at the beginning. (A "normal commit" 
> never
>> creates any emüpty lines in the pre-created comment)
> 
> I could imagine that
> https://github.com/gitgitgadget/git/commit/b2f5171ecc2feb4192acd80f5a6b05c06

> e099e97
> addresses that. Would be good if you could try; just build `pu` from
> https://github.com/git/git (`make install` will install it into your
> `$HOME/bin` and you can test that easily).
> 
> If not, how about giving it a try to fix it yourself? This is open
> source, giving you great power to change the entire source code in your
> local repository as you wish. And of course, with great power... comes
> great responsibility.

I agree, but git isn't a tiny project: Could anybody provide a rough overview
how and where these editor comments are created? Then I could have a look
myself.

> 
>> My Git version is 2.12.3, but the bug is probably quite old...
> 
> You might think that the bug is probably quite old, but what is really
> old is your Git version. The current one is v2.22.0.

With old I mean 1.7.12 or older ;-)

> 
> First order of business should be to verify that it has not been fixed
> in the meantime ;-)

Yeah, but for a fast-paced project you often find yourself busy with updating
all the time, leaving no time for your productive work (like Android
development).
Don't expect too much from someone that drives as 26 year old car... (it's
easier to handle than the new ones) ;-)

Regards,
Ulrich

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

[Johannes Schindelin]

Hi Ulrich,

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.

Ciao,
Johannes

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

[Ulrich Windl]

>>> 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>:
> Hi Ulrich,
> 
> 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.
# 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

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

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

Hi Ulrich,

On Tue, 30 Jul 2019, Ulrich Windl wrote:

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

> # 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
>
>
>
>

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

[Johannes Schindelin]

Re-Cc:ing the Git mailing list.

Please make sure to keep the Git mailing list in Cc:. I get extremely
testy when I see mails asking me for personal help in private. As long
as others can learn from my answers, I am fine with helping. I stop
being fine when I feel like I am mistaken for a free-of-cost, private
help desk.

On Fri, 2 Aug 2019, Johannes Schindelin wrote:

> Hi Ulrich,
>
> On Fri, 2 Aug 2019, Ulrich Windl wrote:
>
> > Thanks for the pointers. After a little digging it looks like some stupid
> > error:
> > To me it seems that status_printf_ln() adds a "\n" at the end of the string,
> > while status_printf() does not.
> > It's unclear to me how the comment char automagically is inserted at the
> > beginning of a line.
> > The magic seems to be in status_vprintf().
> > I'm too old-fashined expecting a function to have a comment describing its
> > purpose ;-)
> > Unfortunately compare_to_commit() is a bit complex for a newbie on git
> > development.
> >
> > To me it looks as if the line before "It looks like you may..." should NOT be a
> > comment line, but an empty line (to be in line with the regular commit comment
> > template). So passing "\nIt looks like you may be committing a merge..." to
> > status_printf_ln() looks wrong to me.
> > And "and try again.\n" seems to create two empty lines that are NOT comment
> > lines.
> > IMHO these to lines should be either comment lines, one comment line or no line
> > at all.
>
> This all sounds like overly complicating things to me. The problem
> itself looks a lot simpler to me than that: All that should be needed is
> to remove the `_lf()`, recompile, and test (on Linux, you can use `make
> install` to install Git into your `~/bin/`).
>
> > How would I design some automated test to check whether the outcome of my patch
> > will produce the desired result?
>
> I am sure that there is a test case that already covers it. If you run
> the test suite (via `make -j$(nproc) test`), naturally this test will
> fail and you have found what to change to verify that this does not
> regress.
>
> If you do not find a test case that way, I am sure that you can use a
> similar `git grep` invocation as the one I gave you earlier to find test
> cases in `t/` that test for similar things, learn from them how we write
> test cases, and add one of your own.
>
> Ciao,
> Johannes
>