Can you explain your setup in more details please? Are you using pre-commit, the tool? Why does it prevent a git checkout -- file on an file unrelated to pre-commit config? Would git restore file bypass this check?

Can you explain your setup in more details please? Are you using pre-commit, the tool?

Yes

Why does it prevent a git checkout -- file on a file unrelated to pre-commit config? Would git restore file bypass this check?

It's similar to a test. I have hooks enabled for post-checkout (In the action project, it's a hook for poetry to sync deps). So it gets triggered by git checkout, but during sync, .pre-commit-hooks.yaml is updated, which pre-commit doesn't like.

OK, thanks. Could you try to see if git restore triggers the same post-checkout hook? That's the modern version of git checkout -- file.

OK, thanks. Could you try to see if git restore triggers the same post-checkout hook? That's the modern version of git checkout -- file.

Yes it triggers it

Thanks! I have to say I find it dumb though 🫠 Because clearly the intent here is to undo modifications in a file unrelated to pre-commit, not checking out another branch.

Erm, ChatGPT says:

From Git’s perspective, a checkout is any operation that updates the working tree from a tree object, not strictly a branch switch.

https://git-scm.com/docs/githooks

post-checkout

This hook is invoked when a git-checkout[1] or git-switch[1] is run after having updated the worktree. The hook is given three parameters: the ref of the previous HEAD, the ref of the new HEAD (which may or may not have changed), and a flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0). This hook cannot affect the outcome of git switch or git checkout, other than that the hook’s exit status becomes the exit status of these two commands.

It is also run after git-clone[1], unless the --no-checkout (-n) option is used. The first parameter given to the hook is the null-ref, the second the ref of the new HEAD and the flag is always 1. Likewise for git worktree add unless --no-checkout is used.

This hook can be used to perform repository validity checks, auto-display differences from the previous HEAD if different, or set working dir metadata properties.

Maybe there's a way to check the flag on your side and do nothing when it's equal to 0 (file retrieved from index)? And/or when the old ref and new ref are the same.

I wonder if #2376 wouldn't fix this too.

But we might want to merge this as a quickfix in the meantime.

It's crazy how many things can get in the way when running Git operations programmatically 😄

I wonder, is it generally valid to ignore post-checkout hooks? AFAIK, for example Git LFS' smudge filter runs after checkout to resolve the LFS pointers and fetch the actual blobs from the LFS server. Not 100% sure whether that's relevant in this case though.