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

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:

quoted

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/`).

quoted

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