0

The problem is simple enough. Git is saying I've added CR (^M) to a file,

me@myComp MINGW64 /c/workspace/service (develop)
$ git diff --check
engine/src/main/java/someFile.java:18: trailing whitespace.
+import some.java.package;^M

but I have core.autocrlf set to true.

me@myComp MINGW64 /c/workspace/service (develop)
$ git config --get core.autocrlf
true

I've not run into this problem before and not sure what's causing it. I've always had core.autocrlf set to true and it's never complained about adding ^M before now.

Here is the output of git config --list with some personal info, gui settings, and branch settings removed just in case it's needed.

core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
push.default=simple
core.autocrlf=true
core.pager=less -x4
core.trustctime=false
core.editor=vim
core.filemode=false
alias.hist=log --pretty=format:'%ad %C(yellow)%h%C(reset) %s %C(yellow)%an%C(reset)' --date=short
alias.logo=log --oneline
alias.superlog=log --decorate --graph
alias.superlogo=log --decorate --graph --oneline
alias.dry-merge=merge --no-commit --no-ff
gui.recentrepo=C:/sts-workspace/kba-service
merge.tool=vimdiff
merge.conflictstyle=diff3
mergetool.prompt=true
mergetool.keeptemporaries=false
mergetool.keepbackups=false
mergetool.trustexitcode=false
diff.tool=vimdiff
difftool.prompt=true
color.ui=true
credential.helper=cache --timeout=3600
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
Captain Man
  • 6,997
  • 6
  • 48
  • 74
  • How did you checked out the file? from which OS? – CodeWizard Jan 11 '16 at 20:22
  • @codeWizard I am on Windows using Git-for-Windows. I checked it out by `git checkout develop`. – Captain Man Jan 11 '16 at 20:23
  • Have you tried refreshing the repo after the config change ? https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings – Rabea Jan 11 '16 at 21:27
  • 1
    @Rabee I didn't *change* the config, it's *always* been that, just to clarify. I did try that series of commands though and at the end I got that the working directory was clean with nothing to commit. – Captain Man Jan 11 '16 at 21:43

1 Answers1

0

As for the reason why it's suddenly decided to do that there's 2 possibilities.

  1. Either there's something specific in the repo's attributes file that's changed
  2. There's something in there with a line that has a windows style line ending so it's decided to default to that style.

Config for windows can be a bitch and is way more hassle then linux / mac, but it's not unmanageable.

I'll just show you my own config (win 7 / mingwin) and you should be able to search what i've done pretty easily. I specifically spent about half a day researching this initially because im kinda OCD just so i could be sure the line endings were always converted to unix based (LF) on commit.

C:\Program Files (x86)\Git\etc\gitconfig
[core]
    autocrlf = false

C:\Program Files (x86)\Git\etc\gitattributes

* text=auto

Note you should probably look up how to config the default git attributes which can also be set on a per project basis if needs be. I use the web one out of these useful templates but your own needs may vary.

C:\Users\BAXTER\.gitconfig

[core]
    eol = lf

P.S. This is probably a duplication to some extent of this

Community
  • 1
  • 1
marblewraith
  • 768
  • 5
  • 16
  • Oh and also you'll have to do a commit if you want to re index all the line endings (see chronials answer on the duplicate). – marblewraith Jan 11 '16 at 22:23