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 >
