Module hook_dispatch_entries 

The hooks directory of one transaction: its plan and one entry per preparation event. What: The hooks directory of one commit transaction: its plan.json and one entry per preparation event. Why: Git starts a hook through core.hooksPath by the entry’s path, so the entry’s name is the event and the executable it starts is the native wrapper. On Windows Git looks for <event>.exe, so entries are hard links or copies with that name.

In TS you’d write (pseudocode):

await writeHookShim({ hooksDirectory, plan, nodePath: process.execPath });

Structs

HookEntryError

What: Why writing a hooks directory failed, naming the path. Why: The caller stops the transaction; a partial hooks directory is never reused.

Functions

hook_entry_name

What: The file name of one preparation event’s entry. Why: Unix names the entry after the event; Windows adds .exe, which Git appends when it looks up a hook.

transaction_no_hooks_directory

What: The hooks directory that is deliberately absent, beside the transaction’s dispatcher directory. Why: The dispatcher’s inner git hook run and the post-commit run point core.hooksPath here, so Git finds no traditional hook (unsupported) and never starts the dispatcher entries again. The directory is never created, because Git treats a missing hooks directory as holding no hook.

write_hook_dispatch

What: Create a new hooks directory holding the plan and one entry per preparation event. Why: The incumbent’s writeHookShim, with native entries instead of a Node program: post-commit has no entry, so it never runs during preparation. A configuration that defines no hook by name gets no entry at all: Git then finds nothing to start, which is what an entry would have done after re-entering this executable, taking the hook lock and running git hook run. The directory must not exist, so nothing half-written is reused.