RE: Interaction between pre-commit hook and git commit <pathspec>

From: Kevin Lyles <klyles@epic.com>
Date: Nov 4, 2026, 16:34 UTC
Message-ID: <CY8PR17MB62362ECA0192916E14234BCBAE682@CY8PR17MB6236.namprd17.prod.outlook.com>
In-Reply-To: <CAPx1Gvd3H2-e5RBoH9e1r0cWqe2uo1tm-eUSop0ffNBc2Pj6tg@mail.gmail.com>

On Tue, November 3, 2026 14:43 Chris Torek <chris.torek@gmail.com> wrote:

Show 7 quoted lines

> If your pre-commit hook attempts modification(s) of the proposed
> snapshot for the new commit, it may need to update more than
> one of these files to make all three conditions hold, and in general
> it just can't. (It's too hard to know what the correct names are,
> since they're different in a work-tree and the "--only" name is
> randomized.)  So pre-commit hooks are restricted to "ok" or
> "not ok" actions.

It sounds like this is one of the "not ok" actions. I did look at updating the "primary" index as well in this case, but ran into issues with the current commit needing to be done before I can get that lock.

Show 5 quoted lines

> Instead of running "git commit" directly, why not run a script
> that does the appropriate "git add"s, then runs "git commit"
> for you?  The pre-commit hook can then inspect to be sure
> that this has occurred, and if not, remind users to run the
> script instead.

This will be rolled out across my company once we figure out how to implement it. The goal is to avoid changing how people interact with git, while still making these changes automatically. In particular, we'd like it to still work when a file is partially staged.

We could pretty easily validate that the files are in the correct state in the pre-commit hook, but we're trying to avoid an extra step for each developer in normal workflows.

I've also looked at implementing this as a clean filter, using a long-running process for performance reasons. However, also for performance reasons, we need to know the full list of files to be cleaned at the start. Otherwise, some commits will take significantly longer than currently, as we need to know the presence/absence of files near the cleaned files to correctly update the file contents. We can batch finding those files, but only if we either know the full list of files being cleaned ahead of time or always get the full list of files in the repository. `git ls-files' takes anywhere from ~500 ms (hot cache) to ~5 seconds in our repository when listing everything, so we'd prefer to avoid that performance hit when possible.