Installation¶
git-tpl is a single binary with no runtime dependencies. libgit2 is compiled into it — with its HTTPS and SSH transports, and, on Linux, its own OpenSSL — so there is nothing to install alongside.
With Homebrew¶
The formula lives in noirbizarre/homebrew-tap rather than homebrew-core, and installs the prebuilt release binary — no Rust toolchain involved.
macOS on Apple silicon and on Intel, and Linux on x86-64. Homebrew on Linux arm64 is not covered: there is no statically linked aarch64 build yet, and a glibc-linked one would fail to load on the distributions Homebrew is most used on.
On Arch Linux¶
Two packages on the AUR, differing only in whether your machine or GitHub's does the compiling:
Both cover x86-64 and aarch64, and both install the man page and the bash, zsh and fish completions.
They deliberately conflict — both install /usr/bin/git-tpl — so pick one, and your AUR helper will offer to
replace the other if it is already there.
From source¶
cargo-binstall downloads the release archive for your
platform instead of compiling.
Falls back to cargo install on a target with no published binary.
Neither installs the man page or the shell completions — Cargo only places the binary — so git tpl --help will
report No manual entry for git-tpl until you generate them:
See Shell completion for the rest.
With mise¶
mise installs git-tpl globally or per project, and pins the version in mise.toml so
everyone working on the project has the same one.
Compiled from source, so it works on every platform mise supports — including the ones the release binaries do not cover.
Either form puts an executable named git-tpl on your PATH through mise's shims, which is all Git needs to
resolve git tpl.
The backend prefix is not optional
mise use git-tpl on its own fails: there is no entry for git-tpl in mise's registry yet, so the tool has to
be named by its backend — cargo: or github:.
Getting the short name is tracked in issue #25.
From a release¶
Download the archive for your platform from the releases page,
extract it and put the binary somewhere on your PATH.
VERSION=X.Y.Z
curl -fsSLO \
https://github.com/noirbizarre/git-tpl/releases/download/$VERSION/git-tpl_${VERSION}_linux-amd64.tar.gz
tar xzf git-tpl_${VERSION}_linux-amd64.tar.gz
mv git-tpl ~/.local/bin/
The archive contains the executable git-tpl at its root, already marked executable — nothing to rename and no
chmod to remember.
Beside it are man/man1/ and completions/, which you can install or ignore; the man page is what makes
git tpl --help work, since Git runs man git-tpl for it.
Assets are named git-tpl_<version>_<platform>.tar.gz, and git-tpl_<version>_windows-amd64.zip on Windows, so
latest/download/ cannot be used without knowing the version — set VERSION to the release you want.
Each release also carries a SHA256SUMS file covering the archives:
curl -fsSLO https://github.com/noirbizarre/git-tpl/releases/download/$VERSION/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS
Releases before 0.4.0
Up to 0.3.0 the assets were bare binaries named git-tpl_<version>_<platform>, with no archive and no
extension.
Anything pinned to those names needs updating.
Verify¶
The binary must be named git-tpl and be on your PATH.
That is how Git resolves subcommands: git tpl looks for an executable called git-tpl.
If that works, you are done.
If git: 'tpl' is not a git command appears, the binary is either not on your PATH or not named git-tpl.
Both invocations work
git tpl update and git-tpl update are the same program.
The Git form is the intended one; the direct form is handy in scripts where you would rather not depend on
Git's subcommand resolution.
Development builds¶
git clone https://github.com/noirbizarre/git-tpl
cd git-tpl
mise run setup # cargo install --path . --force
See Development setup.