gh-symlinks: extension for safely tracking symbolic links in git

[tibberous]

Hi all — built a gh extension for the 20-year-rejected "make git follow symlinks" request. The novel part isn't the following — it's a consent UX that gates the security objection that's blocked this in git core forever (full whitepaper in the repo).

gh extension install tibberous/gh-symlinks
cd /path/to/your/repo
gh symlinks init     # one-time
gh symlinks add hooks

When the user runs add on a symlink, they see a prompt showing the resolved absolute target, the file count, and the byte total, and pick one of three options (.gitignore it, allow once, or allow always for this repo). The approval state is persisted per-repo at .git/info/git-symlinks/config.ini so the prompt only fires for genuinely new links.

Architecture-wise, it's a separate binary that talks to git only through frozen, documented APIs (hash-object, update-index --cacheinfo, post-checkout hook) — same approach git-lfs and git-annex have ridden across 12+ years of git releases without an emergency port. No patch to git itself, no fork to maintain. Cross-platform: Linux, macOS, Windows (Win32 reparse-point APIs handle the bits MinGW's <filesystem> doesn't).

The same binary works as git symlinks ... if you git clone tibberous/git-symlinks and drop it on PATH — the gh extension is just a thin wrapper so it's discoverable via gh extension search symlinks.

Repo: https://github.com/tibberous/git-symlinks
Extension: https://github.com/tibberous/gh-symlinks
Whitepaper: https://github.com/tibberous/git-symlinks/blob/main/WHITEPAPER.md
Releases: v0.1.1, Windows + Linux binaries attached, MIT licensed

Open to feedback on the consent flow + whether anyone wants a different default than "ask the user" (for unattended/CI runs). And if anyone from the gh team thinks the extension should ship binaries directly (so users don't need a separate git-symlinks install), happy to add a gh-extension-precompile workflow — let me know.

Cheers,
Trent