First of all, thank you for your work. The tool helps to organize development workflows a lot. Here is an issue I have encountered:
I'm using pre-commit manually to run lints and checks over my code during development workflow. In particular running it during rebases when conflicts arisen. I found pre-commit to duplicate file names if they are in conflicted state. Some tools misbehaves in case.
Here is a minimal reproducible scenario using git stash conflict:
$ git init .
$ touch README.md
$ git add README.md
$ git commit -am "initial state"
[master (root-commit) 53eaf48] initial state
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md
$ pre-commit run --all-files --verbose
echo.....................................................................Passed
- hook id: echo
- duration: 0s
README.md
$ echo'right'> ./README.md
$ git stash
Saved working directory and index state WIP on master: 53eaf48 initial state
$ echo'left'> ./README.md
$ git add README.md
$ git stash pop
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Recorded preimage for'README.md'
On branch master
Unmerged paths:
(use "git restore --staged <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: README.md
Untracked files:
(use "git add <file>..." to include in what will be committed)
.pre-commit-config.yaml
no changes added to commit (use "git add" and/or "git commit -a")
The stash entry is kept incase you need it again.
$ pre-commit run --all-files --verbose
echo.....................................................................Passed
- hook id: echo
- duration: 0s
README.md README.md README.md
It would be nice if pre-commit could de-duplicate file list prior to feeding it to tools being invoked. Workarounds are welcome.
pre-commit --version
pre-commit 4.6.0
.pre-commit-config.yaml
repos:
- repo: localhooks:
- id: echoname: echoentry: echolanguage: system
hmmm I think actually it should maybe refuse to run instead since linters in an unresolved conflict state are kind of meaningless. there's already precedent for this
use git diff --theirs and git diff --ours to observe differences
resolve conflicting chunks
run pre-commit to run lints and checks
do git add to mark conflict resolved
Steps 2-4 are performed multiple times in a loop until everything is okay.
Currently I have to do git add prior to running pre-commit due to some tools misbehave with duplicated files.
The problem is git add effectively makes git diff --theirs and git diff --ours unavailable (and there is no way to back into state where they work). So it's kinda a bit annoyance and inconvenience.
Obviously if chunks are not resolved, checkers and linters produce a lot of garbage output but it's okay for my use case.
It's possible to use git diff --check specifically to find if there are any unresolved conflict markers in files.
It still could be desired to have a possibility to run pre-commit against files that are already resolved and have no conflict markers. Some kind of force flag to run lints and checks even in conflicting state would suffice.
Oh well. It really was an argument in favor preserving ability to run checks and lints in git conflict state (in case you prefer not to run checks and lints at all)
Activity
asottile commented on Jun 8, 2026
hmmm I think actually it should maybe refuse to run instead since linters in an unresolved conflict state are kind of meaningless. there's already precedent for this
RomanValov commented on Jun 8, 2026
In my workflow its like:
Steps 2-4 are performed multiple times in a loop until everything is okay.
Currently I have to do git add prior to running pre-commit due to some tools misbehave with duplicated files.
The problem is git add effectively makes git diff --theirs and git diff --ours unavailable (and there is no way to back into state where they work). So it's kinda a bit annoyance and inconvenience.
Obviously if chunks are not resolved, checkers and linters produce a lot of garbage output but it's okay for my use case.
It's possible to use git diff --check specifically to find if there are any unresolved conflict markers in files.
It still could be desired to have a possibility to run pre-commit against files that are already resolved and have no conflict markers. Some kind of force flag to run lints and checks even in conflicting state would suffice.
asottile commented on Jun 8, 2026
you probably want to use pre-commit run --files rather than wastefully running it across the whole repo
RomanValov commented on Jun 8, 2026
Oh well. It really was an argument in favor preserving ability to run checks and lints in git conflict state (in case you prefer not to run checks and lints at all)
beanscg commented on Jun 9, 2026
chore: Update pre-commit hooks
chore: Update pre-commit hooks
chore: Update pre-commit hooks
chore: Update pre-commit hooks