Detect mixed line endings

[nagromc]

It would be great if pre-commit-hooks could detect mixed line endings.

In Atom ("Mixed"):

Keywords for future searches: newline, new line, end of line, end-of-line, EOL, line terminator, linebreak, line-break, line break, line-ending, linefeed, line feed, line-feed, LF, carriage return, carriage-return, CR, CRLF, CR-LF

[asottile]

Sounds like a great idea! this could even be a fixer too

[nagromc]

Glad you like the idea :-)

You are right. What do you think if the fixer would be an option of the checker? I mean, sometimes, I want my modifications to be auto corrected. And sometimes, I just want to be aware of the problem and take the decision by myself.

For example:

-   repo: git://github.com/pre-commit/pre-commit-hooks
    sha: v0.8.0
    hooks:
    -   id: mixed-line-ending # or whatever the name; you're the boss
        auto-correct: true

[asottile]

Since it would just be a cli, it would be some sort of argument like this:

-   repo: git://github.com/pre-commit/pre-commit-hooks
    sha: v0.8.0
    hooks:
    -   id: mixed-line-ending
        args: [--fix]

Or should it fix by default and the check-only argument should be something like --no-fix? hmm! I'll leave creative freedom up to you :)

[asottile]

Or maybe even --fix=auto --fix=no --fix=crlf --fix=cr?

[nagromc]

OK, so the hooks can be run independently from pre-commit, right? So it makes sense to have CLI arguments.

I will go for --fix=auto --fix=no --fix=crlf --fix=cr. Without the fix argument, the default behavior will be equivalent to --fix=no, i.e. no formatting.

Please note I'm not used to code in Python, but I'm rigorous in my work and I love to learn. I will try my best and will submit a PR.

[asottile]

Sounds great! I think --fix=auto should be the default personally but up to you :)

[nagromc]

With --fix=auto, the script would convert automatically the line endings right?

If so, if the file contains at least 50% of one line ending type, we assume it becomes the line ending type to convert to. Is it okay?

If you ask me, I would prefer the default to --fix=no 🙂

[asottile]

At least for the rest of the hooks (and in my opinion the best of the hooks!) we prefer fixers over (potentially) annoying non-actionable checkers. At least with the framework it's a lot easier when a hook just does what a human would have to do and all that's required is git add (these types of hooks made it much easier to add pre-commit to massive codebases).

[nagromc]

OK I will go for --fix=auto by default to be consistent with the rest of the project.

Regarding my previous comment, the rule to choose either LF, or CRLF is okay fo you? 50% means we consider only those two types of line ending, i.e. for modern OSes. The other ones (CR, etc.) will be ignored.

[asottile]

👍

we could always extend it to support archaic things like CR later

[friederbluemle]

This is a great idea. It would be useful to be able to exclude, or specifically set the line ending type for certain files (based on a matching pattern).

As an example, the Gradle build tool includes a wrapper task, which automatically generates two scripts gradlew and gradlew.bat. The file gradlew.bat is correctly generated with CRLF line endings (even on Unix-type operating systems), as it is only used on Windows.

The proposed line ending detector/fixer should respect this, and not change the line endings of gradlew.bat to LF, even if the rest of the project is using LF as the end-of-line marker. This could work in a similar way to how trailing-whitespace by default does not trim .md files.

[asottile]

You could alternatively configure something like this:

    -   id: mixed-line-endings
        args: [--fix=lf]
        exclude: '\.bat$'
    -   id: mixed-line-endings
        args: [--fix=crlf]
        files: '\.bat$'

pre-commit allows you to configure duplicate hooks / repositories already -- I don't think we should encode "special" cases based on file extensions (I personally dislike the choices made for the whitespace hook, heh).