Paul Moore added the comment: Martin, thanks for the clarification. When I said "I don't use it much" what I meant was that I've never had it enabled, and for all of the repositories I use, not doing so has never been a problem (until now). In contrast, git's autocrlf feature, which is enabled by default, *has* caused me issues, so I tend to work on the basis that I'm better making sure my tools interoperate properly with Unix-style line endings than making my VCS translate for me.
I was reluctant to enable the eol extension globally because of this. I've just discovered however that extensions can be enabled on a per-repo basis, which is a nice compromise, or I may just enable it globally and learn how to use it properly for other projects. I recall the discussion when the eol extension was created. However, I had mistakenly got the impression that the extension was for people who needed to work with CRLF extensions locally (IIRC, Visual Studio was a tool that preferred CRLF). Clearly that was wrong, and I'll switch to using the eol extension now. (As an aside, one of the downsides of having lurked on the edges of the python-dev community for as long as I have is that you think you know the processes, when actually they've changed since you last checked. Lesson learned - I'll reread the docs next time :-)) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23461> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
