{"thread":{"id":"51517","subject":"blank lines in pre-created merge message","startedAt":"2019-07-24T09:54:15Z","lastAt":"2019-08-02T12:55:45Z","messageCount":7,"participants":["Ulrich Windl","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"379196","messageId":"5D382AC1020000A100032608@gwsmtp.uni-regensburg.de","threadId":"51517","inReplyTo":null,"subject":"blank lines in pre-created merge message","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-07-24T09:54:09Z","receivedAt":"2019-07-24T09:54:15Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"Hi!\n\nI think I had tried bringing this to your attention before, but I think it was\nwithout success.\nThe issue may seem purely cosmetical, while being easy to fix (is my guess):\n\nWhen using \"git merge --no-ff --no-commit ..\", the pre-created merge message\nalways contains two empty lines in between the comment lines. However if there\nwas a merge conflict (being resolved) an extra blank line is added after the\nfirst line.\n\nIn vi those empty lines are easy to spot, and I routinely remove them. But\nmaybe it's better not to create them at the beginning. (A \"normal commit\" never\ncreates any emüpty lines in the pre-created comment)\n\nMy Git version is 2.12.3, but the bug is probably quite old...\n\nRegards,\nUlrich Windl\n\n"},{"id":"379250","messageId":"nycvar.QRO.7.76.6.1907251204310.21907@tvgsbejvaqbjf.bet","threadId":"51517","inReplyTo":"5D382AC1020000A100032608@gwsmtp.uni-regensburg.de","subject":"Re: blank lines in pre-created merge message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-07-25T10:07:10Z","receivedAt":"2019-07-25T10:07:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ulrich,\n\nOn Wed, 24 Jul 2019, Ulrich Windl wrote:\n\n> I think I had tried bringing this to your attention before, but I think it was\n> without success.\n> The issue may seem purely cosmetical, while being easy to fix (is my guess):\n>\n> When using \"git merge --no-ff --no-commit ..\", the pre-created merge message\n> always contains two empty lines in between the comment lines. However if there\n> was a merge conflict (being resolved) an extra blank line is added after the\n> first line.\n>\n> In vi those empty lines are easy to spot, and I routinely remove them. But\n> maybe it's better not to create them at the beginning. (A \"normal commit\" never\n> creates any emüpty lines in the pre-created comment)\n\nI could imagine that\nhttps://github.com/gitgitgadget/git/commit/b2f5171ecc2feb4192acd80f5a6b05c06e099e97\naddresses that. Would be good if you could try; just build `pu` from\nhttps://github.com/git/git (`make install` will install it into your\n`$HOME/bin` and you can test that easily).\n\nIf not, how about giving it a try to fix it yourself? This is open\nsource, giving you great power to change the entire source code in your\nlocal repository as you wish. And of course, with great power... comes\ngreat responsibility.\n\n> My Git version is 2.12.3, but the bug is probably quite old...\n\nYou might think that the bug is probably quite old, but what is really\nold is your Git version. The current one is v2.22.0.\n\nFirst order of business should be to verify that it has not been fixed\nin the meantime ;-)\n\nCiao,\nJohannes\n"},{"id":"379264","messageId":"5D39812C020000A10003265F@gwsmtp.uni-regensburg.de","threadId":"51517","inReplyTo":"nycvar.QRO.7.76.6.1907251204310.21907@tvgsbejvaqbjf.bet","subject":"Antw: Re: blank lines in pre-created merge message","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-07-25T10:15:08Z","receivedAt":"2019-07-25T10:15:14Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Johannes Schindelin schrieb am 25.07.2019 um\n12:07\nin Nachricht :\n> Hi Ulrich,\n> \n> On Wed, 24 Jul 2019, Ulrich Windl wrote:\n> \n>> I think I had tried bringing this to your attention before, but I think it\n\n> was\n>> without success.\n>> The issue may seem purely cosmetical, while being easy to fix (is my\nguess):\n>>\n>> When using \"git merge --no-ff --no-commit ..\", the pre-created merge\nmessage\n>> always contains two empty lines in between the comment lines. However if \n> there\n>> was a merge conflict (being resolved) an extra blank line is added after\nthe\n>> first line.\n>>\n>> In vi those empty lines are easy to spot, and I routinely remove them. But\n>> maybe it's better not to create them at the beginning. (A \"normal commit\" \n> never\n>> creates any emüpty lines in the pre-created comment)\n> \n> I could imagine that\n> https://github.com/gitgitgadget/git/commit/b2f5171ecc2feb4192acd80f5a6b05c06\n\n> e099e97\n> addresses that. Would be good if you could try; just build `pu` from\n> https://github.com/git/git (`make install` will install it into your\n> `$HOME/bin` and you can test that easily).\n> \n> If not, how about giving it a try to fix it yourself? This is open\n> source, giving you great power to change the entire source code in your\n> local repository as you wish. And of course, with great power... comes\n> great responsibility.\n\nI agree, but git isn't a tiny project: Could anybody provide a rough overview\nhow and where these editor comments are created? Then I could have a look\nmyself.\n\n> \n>> My Git version is 2.12.3, but the bug is probably quite old...\n> \n> You might think that the bug is probably quite old, but what is really\n> old is your Git version. The current one is v2.22.0.\n\nWith old I mean 1.7.12 or older ;-)\n\n> \n> First order of business should be to verify that it has not been fixed\n> in the meantime ;-)\n\nYeah, but for a fast-paced project you often find yourself busy with updating\nall the time, leaving no time for your productive work (like Android\ndevelopment).\nDon't expect too much from someone that drives as 26 year old car... (it's\neasier to handle than the new ones) ;-)\n\nRegards,\nUlrich\n\n"},{"id":"379269","messageId":"nycvar.QRO.7.76.6.1907251355500.21907@tvgsbejvaqbjf.bet","threadId":"51517","inReplyTo":"5D39812C020000A10003265F@gwsmtp.uni-regensburg.de","subject":"Re: Antw: Re: blank lines in pre-created merge message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-07-25T11:58:35Z","receivedAt":"2019-07-25T11:58:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ulrich,\n\nOn Thu, 25 Jul 2019, Ulrich Windl wrote:\n\n> >>> Johannes Schindelin schrieb am 25.07.2019 um\n> 12:07\n> in Nachricht :\n> >\n> > On Wed, 24 Jul 2019, Ulrich Windl wrote:\n> >\n> >> When using \"git merge --no-ff --no-commit ..\", the pre-created\n> >> merge message always contains two empty lines in between the\n> >> comment lines. However if there was a merge conflict (being\n> >> resolved) an extra blank line is added after the fiVrst line.\n>\n> [...]\n\n> Could anybody provide a rough overview how and where these editor\n> comments are created?\n\nThe best bet would be to call `git grep` with text in that pre-created\nmerge message, preferably some text that is most likely fixed, i.e. that\ndoes not depend on the current worktree/commit.\n\nIf you give me an example of such a merge message, I can provide you\nwith the appropriate `git grep` call and the code locations to touch.\n\nCiao,\nJohannes\n"},{"id":"379570","messageId":"5D3FE919020000A100032932@gwsmtp.uni-regensburg.de","threadId":"51517","inReplyTo":"nycvar.QRO.7.76.6.1907251355500.21907@tvgsbejvaqbjf.bet","subject":"Re: Antw: Re: blank lines in pre-created merge message","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-07-30T06:52:09Z","receivedAt":"2019-07-30T06:52:15Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Johannes Schindelin schrieb am 25.07.2019 um\n13:58\nin Nachricht :\n> Hi Ulrich,\n> \n> On Thu, 25 Jul 2019, Ulrich Windl wrote:\n> \n>> >>> Johannes Schindelin schrieb am 25.07.2019\num\n>> 12:07\n>> in Nachricht :\n>> >\n>> > On Wed, 24 Jul 2019, Ulrich Windl wrote:\n>> >\n>> >> When using \"git merge ‑‑no‑ff ‑‑no‑commit ..\", the pre‑created\n>> >> merge message always contains two empty lines in between the\n>> >> comment lines. However if there was a merge conflict (being\n>> >> resolved) an extra blank line is added after the fiVrst line.\n>>\n>> [...]\n> \n>> Could anybody provide a rough overview how and where these editor\n>> comments are created?\n> \n> The best bet would be to call `git grep` with text in that pre‑created\n> merge message, preferably some text that is most likely fixed, i.e. that\n> does not depend on the current worktree/commit.\n> \n> If you give me an example of such a merge message, I can provide you\n> with the appropriate `git grep` call and the code locations to touch.\n\nHi!\n\nSorry for the delay:\nOK, here is an example where the auto-generated comment has two blank lines:\n---snip---\nMerge branch 'shared'\n#\n# It looks like you may be committing a merge.\n# If this is not correct, please remove the file\n# .git/MERGE_HEAD\n# and try again.\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch master\n# All conflicts fixed but you are still merging.\n#\n# Changes to be committed:\n# new file: .filelist\n# new file: .gitignore\n...more lines omitted\n---snip---\n\n> \n> Ciao,\n> Johannes\n\n\n\n"},{"id":"379663","messageId":"nycvar.QRO.7.76.6.1907311448280.21907@tvgsbejvaqbjf.bet","threadId":"51517","inReplyTo":"5D3FE919020000A100032932@gwsmtp.uni-regensburg.de","subject":"Re: Antw: Re: blank lines in pre-created merge message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-07-31T13:00:38Z","receivedAt":"2019-07-31T13:00:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ulrich,\n\nOn Tue, 30 Jul 2019, Ulrich Windl wrote:\n\n> >>> Johannes Schindelin schrieb am\n> >>> 25.07.2019 um 13:58 in Nachricht\n> >>> :\n> >\n> > On Thu, 25 Jul 2019, Ulrich Windl wrote:\n> >\n> >> >>> Johannes Schindelin schrieb am\n> >> >>> 25.07.2019 um 12:07 in Nachricht\n> >> >>> :\n> >> >\n> >> > On Wed, 24 Jul 2019, Ulrich Windl wrote:\n> >> >\n> >> >> When using \"git merge ‑‑no‑ff ‑‑no‑commit ..\", the pre‑created\n> >> >> merge message always contains two empty lines in between the\n> >> >> comment lines. However if there was a merge conflict (being\n> >> >> resolved) an extra blank line is added after the fiVrst line.\n> >>\n> >> [...]\n> >\n> >> Could anybody provide a rough overview how and where these editor\n> >> comments are created?\n> >\n> > The best bet would be to call `git grep` with text in that pre‑created\n> > merge message, preferably some text that is most likely fixed, i.e. that\n> > does not depend on the current worktree/commit.\n> >\n> > If you give me an example of such a merge message, I can provide you\n> > with the appropriate `git grep` call and the code locations to touch.\n>\n> Hi!\n>\n> Sorry for the delay:\n> OK, here is an example where the auto-generated comment has two blank lines:\n> ---snip---\n> Merge branch 'shared'\n> #\n> # It looks like you may be committing a merge.\n\nThe command-line I used was:\n\n\tgit grep \"It looks like you may be committing a merge\"\n\nIt points you to\nhttps://github.com/git/git/blob/v2.22.0/builtin/commit.c#L827\n\nAs you can easily see, that message does end in a `\\n`, (and also in the\nother conditional arm, for cherry-pick), and it is printed via\n`status_printf_ln()` (the `_ln` means that it adds another newline), and\nin addition another newline is printed directly after that if block:\n\n\t\tfprintf(s->fp, \"\\n\");\n\nSince this extra empty line is bothering you, how about giving it a try\nto fix it yourself? I guess the best bet is to delete the `_ln` from the\nfunction call, as it avoids changing a message that was already\ntranslated into about a dozen languages (and would have to be translated\nagain if you changed it, even if only to remove a trailing newline).\n\nIf this works for you, please follow\nhttps://github.com/git/git/blob/v2.22.0/Documentation/SubmittingPatches\nto contribute the patch to the Git mailing list.\n\nCiao,\nJohannes\n\n> # If this is not correct, please remove the file\n> # .git/MERGE_HEAD\n> # and try again.\n>\n>\n> # Please enter the commit message for your changes. Lines starting\n> # with '#' will be ignored, and an empty message aborts the commit.\n> # On branch master\n> # All conflicts fixed but you are still merging.\n> #\n> # Changes to be committed:\n> # new file: .filelist\n> # new file: .gitignore\n> ...more lines omitted\n> ---snip---\n>\n> >\n> > Ciao,\n> > Johannes\n>\n>\n>\n>\n"},{"id":"379824","messageId":"nycvar.QRO.7.76.6.1908021453460.46@tvgsbejvaqbjf.bet","threadId":"51517","inReplyTo":"nycvar.QRO.7.76.6.1908021449400.46@tvgsbejvaqbjf.bet","subject":"Re: Antw: Re: blank lines in pre-created merge message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-08-02T12:55:25Z","receivedAt":"2019-08-02T12:55:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Re-Cc:ing the Git mailing list.\n\nPlease make sure to keep the Git mailing list in Cc:. I get extremely\ntesty when I see mails asking me for personal help in private. As long\nas others can learn from my answers, I am fine with helping. I stop\nbeing fine when I feel like I am mistaken for a free-of-cost, private\nhelp desk.\n\nOn Fri, 2 Aug 2019, Johannes Schindelin wrote:\n\n> Hi Ulrich,\n>\n> On Fri, 2 Aug 2019, Ulrich Windl wrote:\n>\n> > Thanks for the pointers. After a little digging it looks like some stupid\n> > error:\n> > To me it seems that status_printf_ln() adds a \"\\n\" at the end of the string,\n> > while status_printf() does not.\n> > It's unclear to me how the comment char automagically is inserted at the\n> > beginning of a line.\n> > The magic seems to be in status_vprintf().\n> > I'm too old-fashined expecting a function to have a comment describing its\n> > purpose ;-)\n> > Unfortunately compare_to_commit() is a bit complex for a newbie on git\n> > development.\n> >\n> > To me it looks as if the line before \"It looks like you may...\" should NOT be a\n> > comment line, but an empty line (to be in line with the regular commit comment\n> > template). So passing \"\\nIt looks like you may be committing a merge...\" to\n> > status_printf_ln() looks wrong to me.\n> > And \"and try again.\\n\" seems to create two empty lines that are NOT comment\n> > lines.\n> > IMHO these to lines should be either comment lines, one comment line or no line\n> > at all.\n>\n> This all sounds like overly complicating things to me. The problem\n> itself looks a lot simpler to me than that: All that should be needed is\n> to remove the `_lf()`, recompile, and test (on Linux, you can use `make\n> install` to install Git into your `~/bin/`).\n>\n> > How would I design some automated test to check whether the outcome of my patch\n> > will produce the desired result?\n>\n> I am sure that there is a test case that already covers it. If you run\n> the test suite (via `make -j$(nproc) test`), naturally this test will\n> fail and you have found what to change to verify that this does not\n> regress.\n>\n> If you do not find a test case that way, I am sure that you can use a\n> similar `git grep` invocation as the one I gave you earlier to find test\n> cases in `t/` that test for similar things, learn from them how we write\n> test cases, and add one of your own.\n>\n> Ciao,\n> Johannes\n>\n"}]}