mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <>
To: Ulrich Windl <>
Subject: Re: Antw: Re: blank lines in pre-created merge message
Date: Fri, 2 Aug 2019 14:55:25 +0200 (CEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

      parent reply	other threads:[~2019-08-02 12:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24  9:54 blank lines in pre-created merge message Ulrich Windl
2019-07-25 10:07 ` Johannes Schindelin
2019-07-25 10:15   ` Antw: " Ulrich Windl
2019-07-25 11:58     ` Johannes Schindelin
2019-07-30  6:52       ` Ulrich Windl
2019-07-31 13:00         ` Johannes Schindelin
     [not found]           ` <>
     [not found]             ` <>
2019-08-02 12:55               ` Johannes Schindelin [this message]

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:

  List information:

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

  git send-email \ \ \ \ \

* 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 public inbox

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