Install

dun is a single static binary with no runtime dependencies. It needs git on PATH and nothing else.

macOS, or Linux with Homebrew

brew tap navjyotnishant/tap
brew install navjyotnishant/tap/dun

Windows

scoop bucket add navjyotnishant https://github.com/navjyotnishant/scoop-bucket
scoop install dun

Linux packages

Every release ships a .deb and an .rpm for amd64 and arm64, so nothing but the package is needed — no Homebrew on Linux, no tarball to unpack.

# Debian, Ubuntu
curl -LO https://github.com/navjyotnishant/whodunit/releases/download/v0.6.0/dun_v0.6.0_linux_amd64.deb
sudo dpkg -i dun_v0.6.0_linux_amd64.deb

# Fedora, RHEL, openSUSE
curl -LO https://github.com/navjyotnishant/whodunit/releases/download/v0.6.0/dun_v0.6.0_linux_amd64.rpm
sudo rpm -i dun_v0.6.0_linux_amd64.rpm

Swap v0.6.0 for the release you want — the releases page lists them — and amd64 for arm64 on ARM machines. The package installs /usr/bin/dun and declares a dependency on git; hooks are still installed per repository by dun init, and configuration still lives in ~/.whodunit. Upgrading is installing the newer package over the old one, then dun repos update.

There is no apt or yum repository yet, so the package does not update itself; dun update tells you when a newer release exists.

From source

go install github.com/navjyotnishant/whodunit/cmd/dun@latest

From a release archive

Download from the releases page, verify it against the published checksums.txt, and put the binary somewhere on your PATH under the name dun — dun.exe on Windows.

shasum -a 256 -c checksums.txt

⚠️ The name matters more than it looks

The git hook resolves the binary by name at commit time:

DUN="$(command -v dun || echo "<the binary that ran init>")"

A binary that is not on PATH as dun falls back to wherever it lived when you ran dun init. That works — until the file moves or is deleted, after which every commit is stamped undetermined, silently.

Downstream, undetermined reads as "no AI was used" rather than "the tool went missing", which is exactly the wrong conclusion. dun init warns when it detects this, and the package managers above avoid it entirely.

Verify the install

dun version
dun verify

dun verify checks the install end to end and names what to fix rather than reporting a bare pass or fail.

Staying current

Upgrading the binary reaches every instrumented repository automatically — the hooks resolve dun from PATH at run time, so a fix lands everywhere at once with no re-init.

Two things do not propagate that way: a hook that did not exist when a repository was instrumented, and a change to the hook script itself. Both are handled without you doing anything — a repository with stale hooks is repaired on the next dun command there, and dun status flags stale repositories in its cross-repo listing.

To fix everything at once:

dun repos update

dun also tells you once a day when a newer release exists, on bare dun only — never from a git hook, because a version check that can hang a commit is worse than an out-of-date binary. Turn it off with:

dun config set version_check off

or set DUN_NO_VERSION_CHECK / DO_NOT_TRACK in the environment.

For the full upgrade path — including the brew upgrade case that reads as a bug, and re-importing the dashboards — see Upgrading.