Jens Mueller wrote:
I'll guess not. Because
core.autocrlf = true means
"Use this setting if you want to have CRLF line endings in your working
directory even though the repository does not have normalized line endings."
(see man git-config)
See here for further explanation:
http://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operati
The part "Moving forward" on github seems rather strange to me.
I tried various settings a few months back, and failed miserably. Nobody
I asked could tell me what the various settings actually did, none of
the online explanations made any sense (*). My takeaway was:
1. do not attempt to use git on Windows
2. write tolf.d and fix all line endings to \n before submission to git
So far, that works.
(*) First off, there were several settings. Nobody could tell me if git
stored the files in its database with canonicalized line endings, what
happened to the original files (were they modified by git?) and what
happens when files were restored from git (line endings left as is,
rewritten, what?), if only the diff programs affected, was the sha hash
affected, etc.
Clearly, at a deep fundamental level, git works with binary files. Not
text files. Attempting to hammer it to work with text files is just doomed.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos