0.3.0

krok 0.3.0

Two fixes, both about hook installation surviving the way repositories are
actually set up: a build step that repoints core.hooksPath, and a bootstrap
script that runs more than once.

The preserved hook now lives under the git directory

When krok takes over a hook that already exists, it keeps a copy and registers
it as the first job so it keeps running. That copy used to go beside the hook it
replaced, under whatever git rev-parse --git-path hooks answered, and the job
resolved it through KROK_HOOKS_DIR at run time. Both follow core.hooksPath —
which is not krok's to set: husky sets it, from a build step, on every fresh
checkout. Installing before that happened left the copy in .git/hooks while
the job looked in .husky, and every commit then failed on the reserved job
with the preserved hook reported missing. A gerrit commit-msg hook is one of
the ones lost that way, which takes the whole repository with it.

The copy now goes to .git/krok/<hook>/existing, named through a new
KROK_GIT_DIR. Nothing outside git moves the git directory, and it is where the
config naming the copy already lives, so the two cannot come apart. It also
keeps krok out of a hooks directory that may be tracked — .husky is, and a
copy written there is untracked noise in every clone.

Upgrading is safe: a file an earlier krok left is still looked for where it was
left, so an upgrade does not read a hook it already installed as unfinished and
preserve it a second time.

add answers instead of refusing when the job is already registered

Registering a job krok already holds was an error. It did not need to be — the
job list already says what the caller asked for, and the command is the same, so
there is nothing ambiguous to report and nothing to write.

The refusal cost more than it looked. Scripts that register hooks run when a
checkout is set up, and again every time it is set up again; under set -e the
refusal fails them, and in a workspace holding several repositories it fails at
the first one that had been set up before, so none of the later ones get their
hooks. Re-running the bootstrap — the obvious move when hooks look wrong — became
the reason the rest of the workspace had none.

krok now reports that the job is already there and succeeds. The wrapper is
still seen to before the answer, so a re-run remains the way a hook file someone
deleted comes back. A different command whose derived key is already taken is
unaffected: it is numbered, as before.

New job variable

Variable	Value
KROK_GIT_DIR	The git directory shared by every worktree

KROK_REPO_ROOT and KROK_HOOKS_DIR are unchanged.