Onefetch: a local Git repository summary for your terminal, without a network call

What onefetch prints, and who actually wants that

Onefetch is a command-line Git information tool. Point it at a local repository and it prints project information and code statistics directly in the terminal. The README states the tool works completely offline, with a focus on performance and customizability.

The audience is narrow and identifiable. If you keep several repositories checked out and you want a quick sense of what is inside one of them without opening an editor, onefetch is built for that. It is also a reasonable fit for shell prompts, dotfile setups, and screenshots of a project, because the output is designed for a terminal rather than a web page.

It is not a repository analytics service. Everything it reports comes from the local checkout and its Git history. If the repository is not cloned, there is nothing for onefetch to read.

Where the numbers come from: local Git history plus a language manifest

The mechanism is visible in the repository layout and the dependency list. Onefetch is a Rust binary that links gix, a Git implementation, and reads the working tree and history of the repository you name. The gix features enabled in Cargo.toml include max-performance-safe, blob-diff, mailmap, index, status, and sha1, which tells you the tool is doing real Git object work rather than shelling out to git.

Language detection is driven by a manifest. The workspace has a separate manifest crate, and the repository root contains languages.yaml, which describes the supported languages. The README says onefetch currently supports more than 100 different programming languages and that unsupported languages can be requested through an issue.

Authors come from Git history. The README is explicit that if the same person committed under different names or emails, they may appear more than once, and that a .mailmap file in the repository merges those entries. The project ships its own .mailmap at the root, which is the same mechanism it expects from you.

Licence detection is handled by the askalono dependency, so the licence line in the output is inferred from files in the repository rather than configured by hand.

Installing onefetch and running it on a real repository

The README points to the release page for Linux, Windows, and macOS binaries, and lists package-manager commands per platform. On macOS the documented command is Homebrew:

brew install onefetch

After that completes, onefetch is on your PATH. On Windows the README gives winget:

winget install onefetch

On Ubuntu the README downloads the .deb from the latest release and installs it with dpkg:

wget https://github.com/o2sh/onefetch/releases/latest/download/onefetch_amd64.deb && sudo dpkg -i ./onefetch_amd64.deb && rm onefetch_amd64.deb

Arch Linux and openSUSE are covered by pacman and zypper respectively. If you prefer to build from source, the Makefile wraps Cargo, and Cargo.toml sets rust-version to 1.88.0, so the toolchain must be at least that new. The Makefile install target is:

cargo install --path "." --features=fail-on-deprecated

The first real use is a single argument. Pass a path to a repository, or change into one and run it bare:

onefetch /path/of/your/repo

You should see the project information and code statistics for that repository printed in the terminal, with no network access required. The default run hides languages classified as prose or data, which is the first thing most people trip over.

Why your Markdown and JSON are missing from the language breakdown

By default, onefetch only displays languages classified as programming and markup. Languages classified as prose, such as Org mode, Markdown, or Text, and languages classified as data, such as JSON, YAML, or TOML, are hidden unless you include them with --type. The README gives this exact invocation:

onefetch --type programming markup prose data

This is a sensible default that surprises people. A documentation-heavy repository can look almost empty on a first run, and the natural conclusion is that detection failed, when in fact the categories were filtered out. The FAQ in the README addresses that confusion directly.

The second common surprise is duplicate authors, which is a property of Git history rather than a bug. The fix is a .mailmap file in the repository, as described above. Neither of these is a defect, but both mean the first run is not necessarily representative of what the tool can show.

Customization, output formats, and what the README does not specify

The README says onefetch can be customized through command-line arguments to display exactly what you want: adjust text styling, disable info lines, ignore files and directories, and output in multiple formats including JSON and YAML. The command-line options are documented in the project wiki rather than the README, so the exact flag names for styling and for the structured output formats are not in the README here. If your workflow depends on parsing onefetch output, read the wiki page before you commit to a schema.

Two more things the README does not document: how the ASCII art and image assets are selected or overridden, and whether there is a configuration file that persists preferences across runs. The repository contains ascii/, image/, and manifest/ workspace members plus a resources/ directory, which suggests the logo and language data are bundled, but the README does not describe a config file. Treat command-line arguments as the configuration surface until you find otherwise.

The offline guarantee is the strongest claim in the README and it is consistent with the dependency list: there is no HTTP client among the dependencies shown. That matters if you are auditing what a developer tool does on a locked-down machine.

Onefetch against Neofetch, and when neither is right

The searches around this project pair it with Neofetch and Nerdfetch, and the comparison is real but shallow. Neofetch reports system information: operating system, kernel, shell, hardware, and a distribution logo. Onefetch reports repository information: languages, authors, and code statistics for a Git working tree. They share a visual idiom, an ASCII or image logo beside a column of facts, and nothing else. If you want to know what machine you are on, Neofetch answers that; onefetch will not.

The more useful contrast is with git itself. Running git log, git shortlog -sne, and git ls-files piped through wc gives you the raw ingredients onefetch aggregates, and those commands are already installed. Onefetch's value is that it collapses the aggregation into one command with a fixed layout, and that it applies language classification and licence detection on top. If you need the underlying data in a form you control, the git plumbing is the better tool; onefetch is the presentation layer.

Where onefetch is the wrong tool: any question about a repository you have not cloned, any comparison across many repositories at once, and any metric that depends on the hosting platform rather than the Git history. The README describes none of those, and the offline design rules them out.

Maintenance, upgrade cost, and the MIT licence

The repository is not archived, and the last push was on 2026-09-20. Releases are frequent enough to matter for packaging: 2.28.0 and 2.28.1 both landed on 2026-08-30, with 2.27.1 before them on 2026-03-19. The workspace version in Cargo.toml is 2.28.1, matching the most recent release.

Upgrade cost is low for most users because the tool is a single binary with no service to run. If you installed through brew, winget, pacman, or zypper, your package manager handles the version. If you built from source, the Makefile install target rebuilds from the current checkout, and the rust-version field of 1.88.0 is the constraint to watch: an older toolchain will not build it. The Cargo.lock file is committed, so a source build is reproducible against that lockfile.

The licence is MIT, declared in Cargo.toml and shipped as LICENSE.md. That is permissive and imposes no obligation on the output onefetch produces, since it generates statistics rather than linking into your code. The package metadata in Cargo.toml also declares a Debian package with the binary installed to /usr/bin/ and a man page at /usr/share/man/man1/onefetch.1. As always, read LICENSE.md yourself rather than treating a summary as legal advice.

Editorial conclusion

Adopt onefetch if you want a fast, offline summary of a local repository and you are comfortable reading its output in a terminal; skip it if you need repository hosting metrics, cross-repo dashboards, or anything that requires a network call, because the README describes none of those. Before relying on the language breakdown, run onefetch --type programming markup prose data in one of your own repositories and confirm the classification matches what you expect.

Frequently asked questions

Official sources

1. License: MIT
2. o2sh/onefetch on GitHub
3. Project website
4. README
5. Releases