2

I had an issue with a file that had inconsistent line ending. My file would show a ^M for every line ending. I ran into this article that shows how to get rid of the ^M character and set the buffer file encoding to fix the issue.

However, I still see the ^M character when I stage and commit my file in Magit. Magit show a file that has ^M as a line ending character even when I fixed this in the file buffer.

Do I need to make Magit aware of my file system encoding. If so, how?

Issue seen in macOS Mojave and Emacs 26.1.

  • I think this is more a git issue than an Emacs issue. Maybe the file is automatically detected as text file or it is marked as text file in .gitattributes. Mark the file type as binary in .gitattributes, do a git checkout MYFILENAME --, remove the Carriage Return just by query-replace, commit the file and restore the old version of .gitattributes. In the net there are recommodations to remove the index of the repository in such cases. That is a insensible sledge-hammer method that does not solve the actual problem (from my point of view). Don't follow that advice. – Tobias Apr 4 at 23:01
  • "how to delete ^M in magit pop-up buffer?" Magit Popup buffers are the dialog buffers that are used to show available key bindings -- they do not contain any diffs. I have changed the title accordingly. – tarsius Apr 5 at 11:02
4

Do I need to make Magit aware of my file system encoding. If so, how?

By configuring Git accordingly using core.eol and related variables described in git-config(1). By asking a search engine about "git end of file" you can find more information.

One complication when it comes to Magit is that it may display diffs for multiple files in the same Emacs buffer. The eol encoding can only be set per buffer, not for a certain area of the buffer, so Magit doesn't even try to use the correct encoding and just assumes lf.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy