Timeline for Make 'git diff' ignore ^M
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 30 at 17:40 | comment | added | Hoshi | The problem with all these settings is when you work on macOS but deploy to Windows via git. If you deploy without CRLF, then you cannot use Notepad to view your production files, you have to use Wordpad, which is overkill. I think the solution would be for Git itself to just handle both kinds of line endings as if they're the same and stop being so picky the extra (or missing) byte! | |
| Dec 12, 2019 at 14:25 | comment | added | XoXo |
If you need to remove some core.* settings, the easiest way is to run this command: git config --global -e. similarly, if you need to edit the current repo's settings, use git config -e
|
|
| Oct 31, 2019 at 17:32 | comment | added | orion elenzil |
super valuable. I spent a long time fooling with editor settings in VSCode and Sublime text trying to get them to stop fooling with line-endings. I finally used a hex-viewer to convince myself that the line-ending on the line I was editing perfectly matched the original version, which let me know the display of the ^M was coming from git diff behavior and didn't represent an actual change to the line ending.
|
|
| Sep 3, 2018 at 10:10 | comment | added | Rolf | I think git needs a bit more complexity, a few more conflicting settings for end of line. I think git should be more concerned about my whitespaces. For example throw an unrelated fatal error and leave the repository in a corrupt state when encountering Mac line endings on a Windows (but not Linux) machine. I mean why would I use a VCS that would mind it's business and let me use whichever line endings I want? I see they're trying, but they should throw in half a dozen more line-ending behaviors, to solve a problem that doesn't exist. They're almost there! Keep it up. | |
| Apr 24, 2018 at 22:59 | comment | added | DimeCadmium |
@Zitrax's comment is false; the default value of core.whitespace is "". If you wanted to, say, enable cr-at-eol and disable blank-at-eol, you would need to set core.whitespace to "cr-at-eol -blank-at-eol". See also git help config.
|
|
| Apr 19, 2018 at 2:38 | comment | added | Lê Quang Duy | SourceInsight keep pushing the ^M character, and git still shows the difference at line endings. @Zitrax's command is the right answer to my case, git diff show nice and clean output. | |
| Oct 9, 2017 at 9:02 | review | Suggested edits | |||
| Oct 9, 2017 at 9:47 | |||||
| Jul 25, 2017 at 12:19 | comment | added | Jānis Elmeris |
For my project (it was checkout out on Windows and I'm viewing it on Linux), cr-at-eol got rid of ^M at the end of lines in git diff all right, but GIT still showed those lines as different, although the line ending was the only difference.
|
|
| Sep 27, 2016 at 11:30 | comment | added | Zitrax |
Note that the line git config --global core.whitespace cr-at-eol would turn off other settings that are default. There are three defaults: blank-at-eol, blank-at-eof and space-before-tab. So to enable cr-at-eol while keeping the others you would need to use git config --global core.whitespace blank-at-eol,blank-at-eof,space-before-tab,cr-at-eol.
|
|
| Dec 23, 2014 at 21:25 | comment | added | Kevin McCarpenter |
For those who find this now, it's worth noting that Checkout Windows-style, commit Unix-style line endings auto-sets core.autocrlf to true
|
|
| Apr 2, 2012 at 20:57 | history | edited | Ryan Lundy | CC BY-SA 3.0 |
Add some details on the settings that seem best for .NET developers
|
| Aug 24, 2011 at 18:58 | history | answered | Ryan Lundy | CC BY-SA 3.0 |