pre-commit/pre-commit-hooks

[check-merge-conflict] False positive on RST files that use '=======' for header notation.

hvdklauw opened this issue · 7 comments

Either ignore that conflict pattern in .rst files or are a option to ignore certain file patterns (I don't want to list all the other file options).

From the docs on http://pre-commit.com you can exclude files with the exclude: pattern

Either that or you can use one more or one fewer =

These workarounds aren't suitable for the needs of cheroot as reported in cherrypy/cheroot#223. We would like to be able to detect merge conflicts in this file just like with any other file. I think the problem is that the check is over-matching. It's detecting content that's not a merge conflict. Git doesn't have this problem when invoking mergetool. Perhaps the hook could be more precise.

mergetool can probably detect when all three markers are there -- but this hook is intended to also prevent the cases where one or more of the markers have been deleted which makes this much trickier (and much more prone to false positives)

I'm not sure what the right answer is here

Just ran into this on two RST files with 7-character underlines:

Depends
=======
Porting
=======

Perhaps the simplest thing is to ignore ======= in RST files? 2/3 checks is better than 0/3.

  • Excluding all RST files with exclude: means they will never be checked for the other two conflict markers

  • Adding or removing an = makes the header look ugly in plaintext

  • More complicated things like looking for a 7-char string on the preceding line, and possibly an empty following line, is probably more effort than it's worth

Does exclude: not work for you? I don't want to make that choice for everyone in this repo and I don't really want to complicate and weaken the checks here

exclude: would stop it running all checks on all RST files, right?

It's better than nothing, but that would mean 145 RST files are never checked at all, which I think is worse than skipping one check in those files.

Perhaps it could be an option for those who happen to run into this?

Another workaround would be to change the ReSTructured text files to use one of the other available characters to mark section headings, for example ###### or ******.