Repository: pre-commit/pre-commit-hooks

Issue #660: check-merge-conflict doesn't catch conflict markers
Created: 2021-10-04T11:47:12Z
.pre-commit-config.yaml
# See https://pre-commit.com for more information
fail_fast: false
repos: [
  {
    repo: "https://github.com/pre-commit/pre-commit-hooks",
    rev: "v4.0.1",
    hooks: [
      # GIT
      { id: "check-merge-conflict" },
      { id: "check-added-large-files" },

      # Sys
      { id: "check-case-conflict" },
      { id: "check-executables-have-shebangs" },
      { id: "check-shebang-scripts-are-executable" },

      # FS
      { id: "check-symlinks" },
      { id: "destroyed-symlinks" },

      # Syntax
      #{ id: "check-yaml" },
      { id: "end-of-file-fixer" },
    ],
  },
]
Example code used for testing
// Dummy comment not to trip shebang detection
#![cfg_attr(
  all(not(debug_assertions), target_os = "windows"),
  windows_subsystem = "windows"
)]

fn main() {
  tauri::Builder::default()
    .run(tauri::generate_context!())
    .expect("BUG: error while running tauri application");
}

If you have questions, please
<<<<<<< HEAD
open an issue
=======
ask your question in IRC.
>>>>>>> branch-a
{
    "version": "1.0.0",
    "devDependencies": {
<<<<<<< HEAD
this is some content to mess with
content to append
=======
totally different content to merge later
>>>>>>> new_branch_to_merge_later
        "type-fest": "2.3.2",
        "typescript": "4.4.2"
    }
}
CLI ouput for pre-commit run --all-files --show-diff-on-failure --verbose
Check for merge conflicts................................................Passed
Check for added large files..............................................Passed
Check for case conflicts.................................................Passed
Check that executables have shebangs.................(no files to check)Skipped
Check that scripts with shebangs are executable..........................Passed
Check for broken symlinks............................(no files to check)Skipped
Detect Destroyed Symlinks................................................Passed
Fix End of Files.........................................................Passed
Format python........................................(no files to check)Skipped
Format JavaScript........................................................Failed
- hook id: format-js
- exit code: 1

Syntax Error: Unexpected token < in JSON at position 1241 (when parsing /opt/dev/braiins/pool/web-ui/packages/toolbox/package.json)
    at JSON.parse (<anonymous>)
    at la.loadFile (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:271:4655)
    at async Function.fromFile (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:271:4165)
    at async Function.tryFind (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:271:3931)
    at async Function.find (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:271:4009)
    at async Kf.setup (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:300:5445)
    at async Ne.addWorkspace (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:304:2080)
    at async Ne.setupWorkspaces (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:304:1866)
    at async Function.find (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:301:1406)
    at async jp.execute (/opt/dev/braiins/pool/web-ui/.yarn/releases/yarn-3.1.0-rc.2.cjs:424:1845)

Duplicate issue #951: Improved experience for check-merge-conflict
Created: 2023-08-23T15:30:09Z
I recently encountered a failure where someone committed code with an unresolved merge conflict. This was a bit of a surprise because we have check-merge-conflict enabled and that hook reported its status as “pass”.
Reading #660 and #881 revealed that this is fairly common because you need to set --assume-in-merge to have it actually check the files any time you're not running in the middle of a merge/rebase and that won't happen normally in situations such as when GitLab/GitHub have done the merge for you and are running the pre-commit CI check afterwards.
I think this could be less confusing in two ways:

When the hook doesn't run, display the status as “skipped”
The name --assume-in-merge is a bit counterintuitive – I think most pre-commit users would assume that the hook is intended to always run by default simply by enabling it. A name like --always-run or a description explaining that the hook by default only runs when making a merge commit could make it clear that at other times it will not run at all.
It's not clear why you would ever want to have the hook installed but not running on most commits but based on #300 it's situations where the ======= pattern would match on things like ReST files which use that for unrelated reasons. It seems like one way to fix this would be to either remove that pattern from this hook or change the logic to require at least two of the patterns to match in a given file. To catch cases where someone manually edited a merge conflict and missed one of the marks, perhaps that's changing the default logic to require 1 match when in a merge and 2+ otherwise, optionally with an argument to force the current behaviour. It could further reduce the noise level by requiring them to match in order (i.e. <<<<<<<  must occur before ======= or >>>>>>>  after).

Closing comment (2023-08-23T16:16:09Z): ok then this is an exact duplicate of #660