On Tue, Oct 08, 2024 at 07:52:33PM +0000, brian m. carlson wrote: > On 2024-10-08 at 19:34:46, Spencer Fretwell wrote: > > Thanks Brian, > > > > It appears sublime auto-normalizes endings to "whatever occurs most > > frequently in the first 32kB". So, I guess it was witnessing the CRLF > > from the verbose output and replacing all lines with CRLF. Thanks for > > the reminder about --renormalize. > > > > Is there any chance for git to support a CRLF magic ignore line, > > particularly considering the variation in standard line ending across > > different platforms? I tried autocrlf=input as well and it sadly > > doesn't normalize the commit message file itself. Either way (magic > > ignore with CRLF or normalizing line endings in the commit message), > > would be appreciated for mixed line ending workflows (especially > > considering WSL) > > The answer is essentially that I don't know. We typically make > decisions on whether we'll accept features when we see the patch. My > guess is that, assuming someone (maybe you) sends a patch, it will > probably be accepted, since I wouldn't expect it would be very difficult > to do or have major impacts on the code. It might, as with any patch, > take a couple of rounds, though. > > I use Linux or rarely other Unix systems and always use LF endings, so I > don't plan to send a patch since this doesn't affect me, but assuming > the patch looked reasonable, I don't see myself having an objection to > it. Hej Spencer, you are probably the first one reporting this, thanks for doing so. I have the suspicion, that your repo has files commit with CRLF, and that leads to a CRLF entering the diff, and that leads your editor to produce CRLF in the commit-message. In order to debug this a little bit, can you run a git ls-files --eol | grep i/crlf in your repo ? In general, when working with cross-platform, or only with windows, it is a good practice to use a .gitattributes file to specify the line endings. Do you have such a file in your repo, and is it commited ?
