{"thread":{"id":"62287","subject":"Verbose Commit Ignore Line Fails via CRLF Line Endings","startedAt":"2024-10-08T18:31:07Z","lastAt":"2024-10-11T17:59:25Z","messageCount":9,"participants":["Spencer Fretwell","brian m. carlson","Torsten Bögershausen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"504469","messageId":"CABa71ByU_9g_6OgJ9PsoQ99oyMspucTBqO-RkB_2W4smTr2RNw@mail.gmail.com","threadId":"62287","inReplyTo":null,"subject":"Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"Spencer Fretwell","fromEmail":"spencer.fretwell@gmail.com","sentAt":"2024-10-08T18:30:53Z","receivedAt":"2024-10-08T18:31:07Z","isPatch":false,"sender":{"key":"spencer.fretwell@gmail.com","avatar":"https://gravatar.com/avatar/d5011a9b9551caa9e911209efa46a4717721ee8a12b55ff42fa692769ee3b82d?d=mp&s=160"},"body":"gc -v produces CRLF file which does not ignore verbose description.\n\nOSX + git-annex (pre-commit hook disabled just in case)\nusing subl -w (sublime text 4) as editor, which indicated the change\nin line endings\n- committing as Unix fixes the issue (workaround, tedious)\n- leaving as Windows is the issue\n\nsee attached bugreport\n\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n- gc -v\n\nWhat did you expect to happen? (Expected behavior)\n\n- line endings respect OS\n- gc without -v uses Unix line endings\n- line ending is visible in sublime (editor = subl -w)\n\nWhat happened instead? (Actual behavior)\n\n- gc -v uses CRLF (Windows) line endings\n- as seen in sublime (editor = subl -w)\n\nWhat's different between what you expected and what actually happened?\n\n- use of CRLF is leaving verbose output in commit message\n\nAnything else you want to add:\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.46.2\ncpu: arm64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nlibcurl: 8.4.0\nzlib: 1.2.12\nuname: Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6020 arm64\ncompiler info: clang: 15.0.0 (clang-1500.3.9.4)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\npost-checkout\npost-merge\npost-receive"},{"id":"504473","messageId":"CABa71BwtEWS79CZwPOa_Nrh1iMrXRo+hyxNBc5F8GsQiwjdapw@mail.gmail.com","threadId":"62287","inReplyTo":"CABa71ByU_9g_6OgJ9PsoQ99oyMspucTBqO-RkB_2W4smTr2RNw@mail.gmail.com","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"Spencer Fretwell","fromEmail":"spencer.fretwell@gmail.com","sentAt":"2024-10-08T18:37:47Z","receivedAt":"2024-10-08T18:38:00Z","isPatch":false,"sender":{"key":"spencer.fretwell@gmail.com","avatar":"https://gravatar.com/avatar/d5011a9b9551caa9e911209efa46a4717721ee8a12b55ff42fa692769ee3b82d?d=mp&s=160"},"body":"On second glance it might involve having a file being committed that\nhas CRLF endings in it.\nCommitting files with LF only does not produce issue.\n\nI suspect git either needs to add support for a magic ignore line\nending with a CRLF,\nor has to sanitize verbose output when that output has CRLF (less ideal)\n\nBug originally seen as early as\n[2018](https://superuser.com/questions/1367811/sometimes-git-includes-the-diff-to-commit-message-when-using-verbose)\n\nOn Tue, Oct 8, 2024 at 12:30 PM Spencer Fretwell\n wrote:\n>\n> gc -v produces CRLF file which does not ignore verbose description.\n>\n> OSX + git-annex (pre-commit hook disabled just in case)\n> using subl -w (sublime text 4) as editor, which indicated the change\n> in line endings\n> - committing as Unix fixes the issue (workaround, tedious)\n> - leaving as Windows is the issue\n>\n> see attached bugreport\n"},{"id":"504475","messageId":"ZwWBxy-wx6bn5tYz@tapette.crustytoothpaste.net","threadId":"62287","inReplyTo":"CABa71ByU_9g_6OgJ9PsoQ99oyMspucTBqO-RkB_2W4smTr2RNw@mail.gmail.com","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-08T19:02:31Z","receivedAt":"2024-10-08T19:02:33Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-08 at 18:30:53, Spencer Fretwell wrote:\n> gc -v produces CRLF file which does not ignore verbose description.\n\nI'm not sure what software you're suggesting here, but we don't\ndistribute any software called \"gc\". I can't imagine `git gc` is\naffecting anything here. Is this maybe an alias for `git commit` or\nsomething else? (I'm going to assume so below.) If so, do you see the\nproblem with a plain `git commit -v`?\n\n> OSX + git-annex (pre-commit hook disabled just in case)\n> using subl -w (sublime text 4) as editor, which indicated the change\n> in line endings\n> - committing as Unix fixes the issue (workaround, tedious)\n> - leaving as Windows is the issue\n> \n> see attached bugreport\n\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> - gc -v\n> \n> What did you expect to happen? (Expected behavior)\n> \n> - line endings respect OS\n> - gc without -v uses Unix line endings\n> - line ending is visible in sublime (editor = subl -w)\n\nDoes this happen if you use a different editor as well, such as vi or\nnano? I don't see this on a Linux system with `git commit -v` using\nNeovim.\n\nAlso, if you do see this problem when you open the editor, can you leave\nthe editor as it is (don't save or modify the file), and change into\nanother terminal window and use something like `xxd -g` or `od -tx1` to\nsee if `.git/COMMIT_EDITMSG` has CRLF pairs (that should show up as `0d\n0a`) or just LF (plain `0a`)?\n\nThe reason I ask this is that I'm wondering if maybe there's a\nconfiguration of your editor that's causing it to switch into a special\ndiff mode with `git commit -v` that it thinks should have CRLF endings.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"504479","messageId":"ZwWDd1_76Z6zH4mP@tapette.crustytoothpaste.net","threadId":"62287","inReplyTo":"CABa71BwtEWS79CZwPOa_Nrh1iMrXRo+hyxNBc5F8GsQiwjdapw@mail.gmail.com","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-08T19:09:43Z","receivedAt":"2024-10-08T19:09:45Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-08 at 18:37:47, Spencer Fretwell wrote:\n> On second glance it might involve having a file being committed that\n> has CRLF endings in it.\n> Committing files with LF only does not produce issue.\n> \n> I suspect git either needs to add support for a magic ignore line\n> ending with a CRLF,\n> or has to sanitize verbose output when that output has CRLF (less ideal)\n> \n> Bug originally seen as early as\n> [2018](https://superuser.com/questions/1367811/sometimes-git-includes-the-diff-to-commit-message-when-using-verbose)\n\nAh, yes, that would probably explain it. Your editor is seeing some\nlines that are CRLF and assuming that the entire file is CRLF, which it\nshould not. In Vim and Neovim, you can do `setl ff=unix` when loading a\nbuffer for `git commit` that will force it to always use Unix line\nendings, and there's probably some functionality in Sublime Text that\nlets you force a particular line ending.\n\nWhat might also help is that if these are intended to be text files, you\ncan set a `.gitattributes` file as outlined in the Git FAQ[0]:\n\n # By default, guess.\n *\ttext=auto\n # Mark all C files as text.\n *.c\ttext\n # Ensure all shell files have LF endings and all batch files have CRLF\n # endings in the working tree and both have LF in the repo.\n *.sh text eol=lf\n *.bat text eol=crlf\n # Mark all JPEG files as binary.\n *.jpg\tbinary\n\nYou can customize the file patterns as you see fit. Once you do that\nand run `git add --renormalize .` (which you should do in the same\ncommit as adding your `.gitattributes` file) and then commit, your text\nfiles will be stored in the repository as LF even though they may have\nCRLF endings in the working tree, and your diff output won't contain\nCRLF.\n\n[0] https://git-scm.com/docs/gitfaq#Documentation/gitfaq.txt#recommended-storage-settings\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"504481","messageId":"CABa71By0WYkbNip6-hmcX2jH1GuHWEx=WBTda5=RV9koR-cVFg@mail.gmail.com","threadId":"62287","inReplyTo":"ZwWDd1_76Z6zH4mP@tapette.crustytoothpaste.net","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"Spencer Fretwell","fromEmail":"spencer.fretwell@gmail.com","sentAt":"2024-10-08T19:34:46Z","receivedAt":"2024-10-08T19:35:00Z","isPatch":false,"sender":{"key":"spencer.fretwell@gmail.com","avatar":"https://gravatar.com/avatar/d5011a9b9551caa9e911209efa46a4717721ee8a12b55ff42fa692769ee3b82d?d=mp&s=160"},"body":"Thanks Brian,\n\nIt appears sublime auto-normalizes endings to \"whatever occurs most\nfrequently in the first 32kB\". So, I guess it was witnessing the CRLF\nfrom the verbose output and replacing all lines with CRLF. Thanks for\nthe reminder about --renormalize.\n\nIs there any chance for git to support a CRLF magic ignore line,\nparticularly considering the variation in standard line ending across\ndifferent platforms? I tried autocrlf=input as well and it sadly\ndoesn't normalize the commit message file itself. Either way (magic\nignore with CRLF or normalizing line endings in the commit message),\nwould be appreciated for mixed line ending workflows (especially\nconsidering WSL)\n\nOn Tue, Oct 8, 2024 at 1:09 PM brian m. carlson\n wrote:\n>\n> On 2024-10-08 at 18:37:47, Spencer Fretwell wrote:\n> > On second glance it might involve having a file being committed that\n> > has CRLF endings in it.\n> > Committing files with LF only does not produce issue.\n> >\n> > I suspect git either needs to add support for a magic ignore line\n> > ending with a CRLF,\n> > or has to sanitize verbose output when that output has CRLF (less ideal)\n> >\n> > Bug originally seen as early as\n> > [2018](https://superuser.com/questions/1367811/sometimes-git-includes-the-diff-to-commit-message-when-using-verbose)\n>\n> Ah, yes, that would probably explain it. Your editor is seeing some\n> lines that are CRLF and assuming that the entire file is CRLF, which it\n> should not. In Vim and Neovim, you can do `setl ff=unix` when loading a\n> buffer for `git commit` that will force it to always use Unix line\n> endings, and there's probably some functionality in Sublime Text that\n> lets you force a particular line ending.\n>\n> What might also help is that if these are intended to be text files, you\n> can set a `.gitattributes` file as outlined in the Git FAQ[0]:\n>\n> # By default, guess.\n> * text=auto\n> # Mark all C files as text.\n> *.c text\n> # Ensure all shell files have LF endings and all batch files have CRLF\n> # endings in the working tree and both have LF in the repo.\n> *.sh text eol=lf\n> *.bat text eol=crlf\n> # Mark all JPEG files as binary.\n> *.jpg binary\n>\n> You can customize the file patterns as you see fit. Once you do that\n> and run `git add --renormalize .` (which you should do in the same\n> commit as adding your `.gitattributes` file) and then commit, your text\n> files will be stored in the repository as LF even though they may have\n> CRLF endings in the working tree, and your diff output won't contain\n> CRLF.\n>\n> [0] https://git-scm.com/docs/gitfaq#Documentation/gitfaq.txt#recommended-storage-settings\n> --\n> brian m. carlson (they/them or he/him)\n> Toronto, Ontario, CA\n"},{"id":"504482","messageId":"ZwWNgc6JY46bmcjE@tapette.crustytoothpaste.net","threadId":"62287","inReplyTo":"CABa71By0WYkbNip6-hmcX2jH1GuHWEx=WBTda5=RV9koR-cVFg@mail.gmail.com","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-08T19:52:33Z","receivedAt":"2024-10-08T19:52:36Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-08 at 19:34:46, Spencer Fretwell wrote:\n> Thanks Brian,\n> \n> It appears sublime auto-normalizes endings to \"whatever occurs most\n> frequently in the first 32kB\". So, I guess it was witnessing the CRLF\n> from the verbose output and replacing all lines with CRLF. Thanks for\n> the reminder about --renormalize.\n> \n> Is there any chance for git to support a CRLF magic ignore line,\n> particularly considering the variation in standard line ending across\n> different platforms? I tried autocrlf=input as well and it sadly\n> doesn't normalize the commit message file itself. Either way (magic\n> ignore with CRLF or normalizing line endings in the commit message),\n> would be appreciated for mixed line ending workflows (especially\n> considering WSL)\n\nThe answer is essentially that I don't know. We typically make\ndecisions on whether we'll accept features when we see the patch. My\nguess is that, assuming someone (maybe you) sends a patch, it will\nprobably be accepted, since I wouldn't expect it would be very difficult\nto do or have major impacts on the code. It might, as with any patch,\ntake a couple of rounds, though.\n\nI use Linux or rarely other Unix systems and always use LF endings, so I\ndon't plan to send a patch since this doesn't affect me, but assuming\nthe patch looked reasonable, I don't see myself having an objection to\nit.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"504777","messageId":"20241011044505.GA1764@tb-raspi4","threadId":"62287","inReplyTo":"ZwWNgc6JY46bmcjE@tapette.crustytoothpaste.net","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-10-11T04:45:05Z","receivedAt":"2024-10-11T04:45:19Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Oct 08, 2024 at 07:52:33PM +0000, brian m. carlson wrote:\n> On 2024-10-08 at 19:34:46, Spencer Fretwell wrote:\n> > Thanks Brian,\n> >\n> > It appears sublime auto-normalizes endings to \"whatever occurs most\n> > frequently in the first 32kB\". So, I guess it was witnessing the CRLF\n> > from the verbose output and replacing all lines with CRLF. Thanks for\n> > the reminder about --renormalize.\n> >\n> > Is there any chance for git to support a CRLF magic ignore line,\n> > particularly considering the variation in standard line ending across\n> > different platforms? I tried autocrlf=input as well and it sadly\n> > doesn't normalize the commit message file itself. Either way (magic\n> > ignore with CRLF or normalizing line endings in the commit message),\n> > would be appreciated for mixed line ending workflows (especially\n> > considering WSL)\n>\n> The answer is essentially that I don't know. We typically make\n> decisions on whether we'll accept features when we see the patch. My\n> guess is that, assuming someone (maybe you) sends a patch, it will\n> probably be accepted, since I wouldn't expect it would be very difficult\n> to do or have major impacts on the code. It might, as with any patch,\n> take a couple of rounds, though.\n>\n> I use Linux or rarely other Unix systems and always use LF endings, so I\n> don't plan to send a patch since this doesn't affect me, but assuming\n> the patch looked reasonable, I don't see myself having an objection to\n> it.\n\nHej Spencer,\n\nyou are probably the first one reporting this, thanks for doing so.\n\nI have the suspicion, that your repo has files commit with CRLF,\nand that leads to a CRLF entering the diff, and that leads your\neditor to produce CRLF in the commit-message.\n\nIn order to debug this a little bit, can you run a\ngit ls-files --eol | grep i/crlf\nin your repo ?\n\nIn general, when working with cross-platform, or only with windows,\nit is a good practice to use a .gitattributes file to specify the\nline endings.\nDo you have such a file in your repo, and is it commited ?\n\n\n\n"},{"id":"504842","messageId":"20241011161030.GA22682@tb-raspi4","threadId":"62287","inReplyTo":"8f3922dd-83d3-4860-a25a-ce52d9d08d7c@mail.shortwave.com","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-10-11T16:10:30Z","receivedAt":"2024-10-11T16:10:44Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Oct 11, 2024 at 02:33:46PM +0000, Spencer Fretwell wrote:\n\n(Please try to avoid top-posting here on this list)\n\n> On Fri Oct 11, 2024, 04:45 AM GMT, Torsten Bögershausen wrote:\n> > On Tue, Oct 08, 2024 at 07:52:33PM +0000, brian m. carlson wrote:\n> >> On 2024-10-08 at 19:34:46, Spencer Fretwell wrote:\n> >> > Thanks Brian,\n> >> >\n> >> > It appears sublime auto-normalizes endings to \"whatever occurs most\n> >> > frequently in the first 32kB\". So, I guess it was witnessing the CRLF\n> >> > from the verbose output and replacing all lines with CRLF. Thanks for\n> >> > the reminder about --renormalize.\n> >> >\n> >> > Is there any chance for git to support a CRLF magic ignore line,\n> >> > particularly considering the variation in standard line ending across\n> >> > different platforms? I tried autocrlf=input as well and it sadly\n> >> > doesn't normalize the commit message file itself. Either way (magic\n> >> > ignore with CRLF or normalizing line endings in the commit message),\n> >> > would be appreciated for mixed line ending workflows (especially\n> >> > considering WSL)\n> >>\n> >> The answer is essentially that I don't know. We typically make\n> >> decisions on whether we'll accept features when we see the patch. My\n> >> guess is that, assuming someone (maybe you) sends a patch, it will\n> >> probably be accepted, since I wouldn't expect it would be very difficult\n> >> to do or have major impacts on the code. It might, as with any patch,\n> >> take a couple of rounds, though.\n> >>\n> >> I use Linux or rarely other Unix systems and always use LF endings, so I\n> >> don't plan to send a patch since this doesn't affect me, but assuming\n> >> the patch looked reasonable, I don't see myself having an objection to\n> >> it.\n> >\n> > Hej Spencer,\n> >\n> > you are probably the first one reporting this, thanks for doing so.\n> >\n> > I have the suspicion, that your repo has files commit with CRLF,\n> > and that leads to a CRLF entering the diff, and that leads your\n> > editor to produce CRLF in the commit-message.\n> >\n> > In order to debug this a little bit, can you run a\n> > git ls-files --eol | grep i/crlf\n> > in your repo ?\n> >\n> > In general, when working with cross-platform, or only with windows,\n> > it is a good practice to use a .gitattributes file to specify the\n> > line endings.\n> > Do you have such a file in your repo, and is it commited ?\n> >\n> >\n> >\n> Hi Torsten,\n>\n> To catch you up, yes the problem involved commiting a long CRLF file whose line endings predominated the commit message, so my editor assumed the endings should be CRLF for the message and normalized all lines including the magic ‘comment below’ line. This in turn appears to nullify the magic line so the patch itself saves to the commit message\n>\n> Would an attribute file LF the patch contents? I guess it should given the patch is what is comitted. The other solution would be for git to handle the CRLF magic line better, either sanitizing to LF during comment removal in the commit message or just by interpreting the magic line with CRLF as still a magic line. One is a process update the other a syntax update, but other than knowing that I am unfamiliar with the got codebase and this wary about attempting a patch…\n\nI am not sure, if I understand your question fully correct.\nAs far as I know, Git does not manipulate the line endings\nin the commit message. That is something that can be done.\nHowever, it seems that 2 things come together at you side:\na) Files are commited with CRLF.\n That is not recommendet, I would say.\n Could you do me a favorite and run\n git ls-files --eol | grep i/crlf\n\nb) Your editor makes the decision to convert all LF into CRLF\n That is, hm, fixable by either using a different editor\n or setting\n git config --global core.editor notepad (under windows).\n The \"notepad\" executable under Windows is a shell script,\n which converts the commit message into CRLF, invokes notepad.exe,\n and converts the commit message back into LF, before handing it\n to Git.\n That will do the trick as well.\n\nIf someone wants to send a patch to normalize the line endings\nfrom the commit-message, I am happy to review it.\n\n"},{"id":"504861","messageId":"xmqqmsjaed1h.fsf@gitster.g","threadId":"62287","inReplyTo":"ZwWNgc6JY46bmcjE@tapette.crustytoothpaste.net","subject":"Re: Verbose Commit Ignore Line Fails via CRLF Line Endings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-11T17:59:22Z","receivedAt":"2024-10-11T17:59:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n>> Is there any chance for git to support a CRLF magic ignore line,\n>> particularly considering the variation in standard line ending across\n>> different platforms? I tried autocrlf=input as well and it sadly\n>> doesn't normalize the commit message file itself. Either way (magic\n>> ignore with CRLF or normalizing line endings in the commit message),\n>> would be appreciated for mixed line ending workflows (especially\n>> considering WSL)\n>\n> The answer is essentially that I don't know. We typically make\n> decisions on whether we'll accept features when we see the patch. My\n> guess is that, assuming someone (maybe you) sends a patch, it will\n> probably be accepted, since I wouldn't expect it would be very difficult\n> to do or have major impacts on the code. It might, as with any patch,\n> take a couple of rounds, though.\n>\n> I use Linux or rarely other Unix systems and always use LF endings, so I\n> don't plan to send a patch since this doesn't affect me, but assuming\n> the patch looked reasonable, I don't see myself having an objection to\n> it.\n\nI do not offhand see a downside if we loosened the detection of the\ncut line a bit. What is happening on the Git end (I do not care how\nEditor screws up and munges what we wrote before \"Do not modify or\nremove the line above\"---to us, it looks like the user did not honor\nthat instruction) is:\n\nwt-status.c defines cut_line[] to be\n\n static const char cut_line[] =\n \"------------------------ >8 ------------------------\\n\";\n\nIOW, we insist that after the dashes we have LF.\n\nThen wt-status.c:wt_status_locate_end() does this:\n\n size_t wt_status_locate_end(const char *s, size_t len)\n {\n const char *p;\n struct strbuf pattern = STRBUF_INIT;\n\n strbuf_addf(&pattern, \"\\n%s %s\", comment_line_str, cut_line);\n if (starts_with(s, pattern.buf + 1))\n len = 0;\n else if ((p = strstr(s, pattern.buf))) {\n\t\t\tsize_t newlen = p - s + 1;\n\t\t\t...\n\nThat is, if the buffer begins with the cut line (including the LF at\nthe end of the line, without any CR before it), we found it at the\nbeginning of the buffer at len==0, otherwise if we find a region of\nmemory that begins with LF, followed by the scissors, followed by LF\n(again, without allowing CR before it), we have a match there.\n\nThat is reasonable as long as the user does not muck with the line\nthat we told them not to touch. In this case, the editor is\ncorrupting the line without being instructed by the user so the user\ncannot do much about it.\n\nWe could loosen the rule by doing something along the following line:\n\n - define the cut_line constant without LF at the end of the line.\n\n - teach wt_status_append_cut_line() to compensate for the lack of\n LF in cut_line.\n\n - teach wt_status_locate_end() to notice and ignore CR if it\n appears at the end of the cut_line.\n\nI'll go offline at the end of this week, so I will stop here at\nillustrating the above approach in the form of an untested patch\nbelow. I am sure I'd have many off by one errors in it, but it\nshould be sufficient to outline the idea.\n\n wt-status.c | 23 ++++++++++++++++++-----\n 1 file changed, 18 insertions(+), 5 deletions(-)\n\ndiff --git c/wt-status.c w/wt-status.c\nindex 6a8c05d1cf..b54bc5de81 100644\n--- c/wt-status.c\n+++ w/wt-status.c\n@@ -39,7 +39,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@@ -1095,15 +1095,28 @@ static void wt_longstatus_print_other(struct wt_status *s,\n \tstatus_printf_ln(s, GIT_COLOR_NORMAL, \"%s\", \"\");\n }\n \n+static int at_eol(const char *s, size_t len, size_t loc)\n+{\n+\tif (len <= loc)\n+\t\treturn 0;\n+\tif (s[loc] == '\\r')\n+\t\tloc++;\n+\tif (len <= loc)\n+\t\treturn 0;\n+\treturn s[loc] == '\\n';\n+}\n+\n size_t wt_status_locate_end(const char *s, size_t len)\n {\n \tconst char *p;\n \tstruct strbuf pattern = STRBUF_INIT;\n \n-\tstrbuf_addf(&pattern, \"\\n%s %s\", comment_line_str, cut_line);\n-\tif (starts_with(s, pattern.buf + 1))\n+\tstrbuf_addf(&pattern, \"%s %s\", comment_line_str, cut_line);\n+\tif (starts_with(s, pattern.buf) && at_eol(s, len, pattern.len))\n \t\tlen = 0;\n-\telse if ((p = strstr(s, pattern.buf))) {\n+\telse if ((p = strstr(s, pattern.buf)) &&\n+\t\t (s < p && p[-1] == '\\n') &&\n+\t\t at_eol(p, p - s, pattern.len)) {\n \t\tsize_t newlen = p - s + 1;\n \t\tif (newlen < len)\n \t\t\tlen = newlen;\n@@ -1116,7 +1129,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, comment_line_str, \"%s\", cut_line);\n+\tstrbuf_commented_addf(buf, comment_line_str, \"%s\\n\", cut_line);\n \tstrbuf_add_commented_lines(buf, explanation, strlen(explanation), comment_line_str);\n }\n \n\n"}]}