2009/9/5 "Martin v. Löwis" <martin@v.loewis.de>:
FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad requires /r/n, but do IDLE and other editors (on Windows) that people would actually use to create/edit such files? I would personally be willing to install a notepad replacement if needed to quickview such files.
Visual Studio will create files with CRLF endings. Please don't talk people out of using Visual Studio for development. More generally: please accept that it is consensus that this *has* to be fixed, and that it *is* a problem on Windows.
(Disclaimer: I have no problem with accepting that the extension is needed - the following is for clarity, in particular to help me understand how the hook will be used) There are 2 separate questions - (1) what is held in the repository, and (2) what is in the user's workspace. The two clearly interact. Taking (2) first, there are *some* files (very few, I believe) that require specific line endings (CRLF - Visual Studio build files, is my understanding). There are also tools that require fixed line endings for input (notepad, Visual Studio). Finally, tools create new files with certain line endings by default (pretty much guaranteed to be platform-native, I'd expect). The result is that user workspaces *may* (quite probably, will) contain files with a mixture of line endings if care is not taken. As regards (1), I assume that for "text" files, a consistent EOL convention (assumed LF) should be used in the repository. It's not clear to me what should be held in the repo for the files requiring specific line endings - my instinct is that they should be treated as "binary" and stored in the repo with the mandated line endings, and checked out unchanged. So we have the following situation: - Some "binary" files which should never be converted - Some "text" files, which must be held in LF form in the repo My view is that how I store text files in my workspace is entirely up to me (and the capabilities of my tools). So, how files get checked out should not be centrally mandated. (Hmm, that may complicate matters). How files are checked in is crucial, so a setting is required which ensures that each file so marked is converted to LF format on checking - effectively working like universal newline mode. So, the issues: 1. Given that the "problematic" tools (notepad and Visual Studio) are Windows tools, we seem to be back to the idea that this extension is only needed by Windows developers. As I understood the consensus to be that the extension should be for all users, I suspect I've missed something. 2. Allowing text files to be checked out in whatever form the user prefers seems complicated. The alternative would likely be to say test files are checked out in "native" form. That works, but would irritate me as I work on Windows, but prefer strongly to use LF line endings (yes, I realise that makes me an oddball...) I'd put up with it if it was the consensus to do this, of course. 3. Is there a realistic possibility that a user could edit one of the CRLF-requiring files with a tool that converts it to LF? If so, is there a need to trap that programmatically (as opposed to simply accepting that this equates to the individual accidentally breaking the build, no worse or better than checking in a C file with a syntax error)? Is this a fair summary? Paul