On Fri, Oct 11, 2024 at 02:33:46PM +0000, Spencer Fretwell wrote: (Please try to avoid top-posting here on this list) > On Fri Oct 11, 2024, 04:45 AM GMT, Torsten Bögershausen <mailto:tboegi@xxxxxx> wrote: > > 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 ? > > > > > > > Hi Torsten, > > 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 > > 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… I am not sure, if I understand your question fully correct. As far as I know, Git does not manipulate the line endings in the commit message. That is something that can be done. However, it seems that 2 things come together at you side: a) Files are commited with CRLF. That is not recommendet, I would say. Could you do me a favorite and run git ls-files --eol | grep i/crlf b) Your editor makes the decision to convert all LF into CRLF That is, hm, fixable by either using a different editor or setting git config --global core.editor notepad (under windows). The "notepad" executable under Windows is a shell script, which converts the commit message into CRLF, invokes notepad.exe, and converts the commit message back into LF, before handing it to Git. That will do the trick as well. If someone wants to send a patch to normalize the line endings from the commit-message, I am happy to review it.
