{"thread":{"id":"59580","subject":"[PATCH] git-commit: fix cut_line behavior with CRLF","startedAt":"2023-04-11T22:55:39Z","lastAt":"2023-04-11T23:10:40Z","messageCount":2,"participants":["Robert Boyd III via GitGitGadget","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"475180","messageId":"pull.1513.git.1681253732794.gitgitgadget@gmail.com","threadId":"59580","inReplyTo":null,"subject":"[PATCH] git-commit: fix cut_line behavior with CRLF","fromName":"Robert Boyd III via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2023-04-11T22:55:32Z","receivedAt":"2023-04-11T22:55:39Z","isPatch":true,"sender":{"key":"name:Robert Boyd III","avatar":null},"body":"From: Robert Boyd III <git@robertboyd.dev>\n\nOn Windows with certain editor (mis)configurations, the cut_line that is\nused when commit.verbose is turned on doesn't work correctly because\nCOMMIT_EDITMSG is rewritten with Windows line endings. This used to\nhappen on old versions of VSCode, but I can't seem to reproduce it\nanymore without explicitly setting the line-endings to Windows. Even so,\nI think it would be sensible to fix this for good, even in the face of\nbad editor behavior.\n\nThis patch moves the \\n ending out of the detection string constant, so\nthat regardless of the line endings, the cut_line is detected correctly.\n\nSigned-off-by: Robert Boyd III <git@robertboyd.dev>\n---\n    git-commit: fix cut_line behavior with CRLF\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1513%2Frob-3%2Fmaint-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1513/rob-3/maint-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1513\n\n wt-status.c | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 3162241a570..85904362fe5 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -24,7 +24,7 @@\n #define UF_DELAY_WARNING_IN_MS (2 * 1000)\n \n static const char cut_line[] =\n-\"------------------------ >8 ------------------------\\n\";\n+\"------------------------ >8 ------------------------\";\n \n static char default_wt_status_colors[][COLOR_MAXLEN] = {\n \tGIT_COLOR_NORMAL, /* WT_STATUS_HEADER */\n@@ -1090,7 +1090,7 @@ void wt_status_append_cut_line(struct strbuf *buf)\n {\n \tconst char *explanation = _(\"Do not modify or remove the line above.\\nEverything below it will be ignored.\");\n \n-\tstrbuf_commented_addf(buf, \"%s\", cut_line);\n+\tstrbuf_commented_addf(buf, \"%s\\n\", cut_line);\n \tstrbuf_add_commented_lines(buf, explanation, strlen(explanation));\n }\n \n\nbase-commit: 73876f4861cd3d187a4682290ab75c9dccadbc56\n-- \ngitgitgadget\n"},{"id":"475181","messageId":"xmqq35569frq.fsf@gitster.g","threadId":"59580","inReplyTo":"pull.1513.git.1681253732794.gitgitgadget@gmail.com","subject":"Re: [PATCH] git-commit: fix cut_line behavior with CRLF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-11T23:10:33Z","receivedAt":"2023-04-11T23:10:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert Boyd III via GitGitGadget\" <gitgitgadget@gmail.com> writes:\n\n> From: Robert Boyd III <git@robertboyd.dev>\n>\n> On Windows with certain editor (mis)configurations, the cut_line that is\n> used when commit.verbose is turned on doesn't work correctly because\n> COMMIT_EDITMSG is rewritten with Windows line endings. This used to\n> happen on old versions of VSCode, but I can't seem to reproduce it\n> anymore without explicitly setting the line-endings to Windows. Even so,\n> I think it would be sensible to fix this for good, even in the face of\n> bad editor behavior.\n>\n> This patch moves the \\n ending out of the detection string constant, so\n> that regardless of the line endings, the cut_line is detected correctly.\n\nThe problem description does make sense.\n\nRemoving the hardcoded LF from the constant is a good idea, because\nwe would want to allow CRLF after the cut_line[] constant on Windows\nwhile we usually expect LF there.  The code that inserts cut_line[]\ninto the output wants to have the LF at the end of the input string,\nand your patch correctly compensates for the loss of LF, so that is\ngood, too.\n\nBut wt_status_locate_end() should be taught about our expectation\nthat cut_line[] we seek is supposed to be followed by either LF or\nCRLF.  Otherwise we would mistake any random line that begins with\nthe cut_line[] constant, followed by arbitrary garbage that is not\nend of line.\n\nThanks.\n\n>  wt-status.c | 4 ++--\n>  1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/wt-status.c b/wt-status.c\n> index 3162241a570..85904362fe5 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -24,7 +24,7 @@\n>  #define UF_DELAY_WARNING_IN_MS (2 * 1000)\n>  \n>  static const char cut_line[] =\n> -\"------------------------ >8 ------------------------\\n\";\n> +\"------------------------ >8 ------------------------\";\n>  \n>  static char default_wt_status_colors[][COLOR_MAXLEN] = {\n>  \tGIT_COLOR_NORMAL, /* WT_STATUS_HEADER */\n> @@ -1090,7 +1090,7 @@ void wt_status_append_cut_line(struct strbuf *buf)\n>  {\n>  \tconst char *explanation = _(\"Do not modify or remove the line above.\\nEverything below it will be ignored.\");\n>  \n> -\tstrbuf_commented_addf(buf, \"%s\", cut_line);\n> +\tstrbuf_commented_addf(buf, \"%s\\n\", cut_line);\n>  \tstrbuf_add_commented_lines(buf, explanation, strlen(explanation));\n>  }\n>  \n>\n> base-commit: 73876f4861cd3d187a4682290ab75c9dccadbc56\n"}]}