1

After running our build process, some files are showing up in SourceTree with whitespace-only changes. Leaving aside discussions about whether auto-generated files should be included in source control, my problem is this:

Files show up in the uncommitted window. If I attempt to commit them, I get the error below.

Ideally I'd like to have SourceTree be smart enough to not display these files as modified in the first place. Is there a good way to accomplish this?

git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F C:----\fc1hkokv.mod -- ----.js

On branch feature/14006-clinical-notes Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory)

modified: xxxx.js no changes added to commit (use "git add" and/or "git commit -a")

warning: LF will be replaced by CRLF in xxx.js. The file will have its original line endings in your working directory.

Adam Rackis
  • 82,527
  • 56
  • 270
  • 393
  • Looks like those are newline characters changed. `LF will be replaced by CRLF in xxx.js`. Files are generated in Unix-mode, with LFs. Then they are commited with substitution to CRLF, and probably pulled to another user with different settings for newline chars. – Nick Volynkin Jun 02 '15 at 19:15
  • Thanks @Nick - is there a way to tell SourceTree to ignore changes limited to just this? – Adam Rackis Jun 02 '15 at 19:24
  • That's not about SourceTree. Just setup the core.autocrlf the right way on all machines. http://www.git-scm.com/docs/git-config – Nick Volynkin Jun 02 '15 at 19:25
  • What I mean is that if you set the right configuration, you won't need to tinker with SourceTree. Git is capable of handling endlines between different operation systems. OS X and Linux use `LF`, Windows uses `CRLF`, Git can store in any mode. But you need to have unified mode for all developers. Right now it looks like one pushes LFs and some other pushes CRLFs. – Nick Volynkin Jun 02 '15 at 19:27
  • @Nick - I added `autocrlf=true` into .git/core under `[core]` but still these same files show up with the same meaningless end of file change, that I can't commit and have to just discard. Did I miss something from your comments? – Adam Rackis Jun 02 '15 at 19:37
  • There's also `core.whitespace` if that is indeed about whitespace. http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration – Nick Volynkin Jun 02 '15 at 19:42
  • @Nick - Windows 8.1. The files are generated by a Node process, which I suspect explains the cr/lf difference. I'll have a look at that link, thanks! – Adam Rackis Jun 02 '15 at 19:52
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/79457/discussion-between-nick-volynkin-and-adam-rackis). – Nick Volynkin Jun 02 '15 at 19:52
  • This situation is thoroughly discussed [here](http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf). – Thiago Sá Jun 06 '15 at 02:01

0 Answers0