FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Duplicate files when doing `pre-commit run --all-files` during git conflict · Issue #3706 · pre-commit/pre-commit · GitHub

Repository navigation

Duplicate files when doing pre-commit run --all-files during git conflict #3706

Closed

Description

search you tried in the issue tracker

merge / conflict / duplicate

describe your issue

Hello,

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 in case 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: local
    hooks:
    - id: echo
      name: echo
      entry: echo
      language: system

~/.cache/pre-commit/pre-commit.log (if present)

Activity

  1. asottile commented on Jun 8, 2026

    Member

    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

  2. RomanValov commented on Jun 8, 2026

    Author

    In my workflow its like:

    1. bump into conflict
    2. use git diff --theirs and git diff --ours to observe differences
    3. resolve conflicting chunks
    4. run pre-commit to run lints and checks
    5. 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.

  3. asottile commented on Jun 8, 2026

    Member

    you probably want to use pre-commit run --files rather than wastefully running it across the whole repo

  4. RomanValov commented on Jun 8, 2026

    Author

    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)

  5. beanscg commented on Jun 9, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL