# Tig: a text-mode Git repository browser for the terminal

> Tig is an ncurses-based interface for Git that browses history, stages changes at chunk level, and pages Git command output. It is built for developers who already live in a shell and want Git's model without retyping plumbing commands.

**jonas/tig** — Text-mode interface for git

- Repository: https://github.com/jonas/tig
- Website: https://jonas.github.io/tig/
- Stars: 13,351 · Forks: 668
- Language: C
- License: GPL-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jonas-tig

## What Tig replaces in a Git workflow

Git's command line is precise but not visual. To review a branch you type git log, then git show, then git diff, then git add -p, each time re-specifying the commit or path. Tig collapses that into one ncurses window. The README describes it as functioning mainly as a Git repository browser, and also as a helper for staging changes at chunk level and as a pager for output from various Git commands.

The audience is narrow and specific: developers who keep a terminal open, who already understand Git's object model, and who find a browser tab slower than a keypress. If you do not know what a hunk is, Tig will not teach you; it exposes the same operations Git does, just with a cursor. If you prefer a mouse and a side-by-side diff, this is the wrong layer entirely.

## How the ncurses front end talks to Git

Tig is written in C and links against ncurses, which the Makefile makes explicit: TIG_NCURSES defaults to -lcurses and is folded into LDLIBS. It is not a reimplementation of Git. It drives the git binary and renders the result, so the Git version on your PATH matters. The README's bug-report checklist asks for tig -v, uname -a, and git -v together, which tells you the maintainers treat the ncurses build and the Git build as part of the same failure surface.

The repository layout confirms the split: src/ holds the C sources, doc/ holds the man pages and the manual, contrib/ holds per-kernel configuration fragments included by the Makefile, and test/ holds the test suite and tools such as test/tools/test-graph. Behaviour is configurable through tigrc, documented as doc/tigrc.5.adoc and installed as a man page. That file is where key bindings, colours, and command aliases live, which is why the manual is a separate document from the man page.

## Installing Tig and opening a repository

The README does not carry install steps itself; it points at INSTALL.adoc for build and install instructions, and at the releases page for tarballs. The Makefile shows the shape of a source build: prefix defaults to $(HOME), bindir to $(prefix)/bin, and DESTDIR is available for staged installs. In other words, a plain make install without overrides puts the binary under your home directory, not /usr/local.

A source build follows the usual autotools path. autogen.sh generates the configure script, and configure.ac is the input to it.

```bash
./autogen.sh
./configure
make
make install
```

After that, running tig with no arguments in a repository opens the main view. The README gives no argument list, so check the manual for the full set. Version reporting is documented in the bug-report section:

```bash
tig -v
```

That prints the Tig and ncurses versions, which is the first thing to capture if the interface renders incorrectly. For a first real use, open a repository and move through the log view, then select a commit and press Enter to see its diff. Staging at chunk level is the second capability the README names, so the next step is to open the status view and stage a hunk rather than a whole file. The exact key bindings are not in the README; they are in the manual and in tigrc.

## Where Tig stops being the right tool

Tig inherits Git's constraints rather than softening them. It has no merge conflict resolution UI in the sense a graphical client does, and it does not model a working copy independently of Git. If your repository is enormous, the browser is only as fast as the git commands underneath it, and every view is a fresh invocation of those commands. The README describes no index or cache layer.

The build is the other constraint. This is a C program compiled against ncurses, distributed primarily as source and tarballs. On a system without a C toolchain or ncurses headers, installation is not a one-line affair. The Makefile's per-kernel includes in contrib/ exist precisely because linking curses differs across platforms, and the CI badges in the README cover Linux, macOS, and AppVeyor for Windows. Windows users in particular should read INSTALL.adoc before assuming the ncurses path works the way it does on Unix.

Finally, configuration is a text file. There is no settings dialog. If you want a different colour scheme or a rebind, you edit tigrc and reload.

## Tig versus lazygit and other Git TUIs

The obvious comparison is lazygit, which people search for alongside Tig. The difference in approach is architectural. Tig is a viewer and pager layered over the git binary, with a configuration file and a manual, and it has been in that shape since well before the current crop of terminal UIs. lazygit is a full application with its own panel-driven workflow and its own interaction model.

That distinction matters in practice. A pager-style tool composes with your existing Git usage: you can pipe output into it, and its views map onto commands you already know. A panel-driven application asks you to learn its own mental model and tends to own more of the workflow. Tig's README explicitly frames the pager role, which is the clearest statement of intent available.

Neither is strictly better. If you want a self-contained TUI that manages branches, stashes, and commits through menus, lazygit is the more complete application. If you want something that stays close to Git's own vocabulary and can act as a pager for arbitrary Git output, Tig's design is the closer fit.

## Maintenance, releases, and the GPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-19. Release cadence is visible in the tags: tig-2.6.1 on 2026-06-13, tig-2.6.0 on 2025-09-16, and tig-2.5.12 on 2025-02-06. That is roughly one feature release a year with patch releases between, which is a slow but real cadence. The Makefile pins VERSION to 2.6.1, so a source checkout without a .git directory reports that version.

Upgrade cost is low if you build from source, because the binary is small and self-contained, but it is not zero: ncurses and Git versions both enter the picture, and the README's bug template asks for both. Distribution packages may lag the tagged release, so check which version your package manager ships before filing anything.

Tig is licensed GPL-2.0, with COPYING at the repository root. That is a copyleft licence. If you redistribute a modified Tig binary, the licence's terms apply to your distribution; if you merely run it as a tool, the usual reading is that no obligation attaches to your own code. This is not legal advice, and the COPYING file is the authoritative text.

## Conclusion

Adopt Tig if you work in a terminal, want to inspect history and stage hunks without leaving it, and are comfortable installing from source or a package manager. Skip it if you need a graphical diff tool, a Git GUI with mouse-driven staging, or a client that bundles its own Git implementation; Tig wraps the Git you already have. Before you commit to it, run tig -v against your ncurses build, read INSTALL.adoc for your platform's dependencies, and check whether your distribution packages 2.6.1 or an older release.

## FAQ

### What is jonas/tig?

It is an ncurses-based text-mode interface for Git, written in C. The README describes it as mainly a Git repository browser that can also stage changes at chunk level and act as a pager for Git command output.

### How do I install Tig?

The README points to INSTALL.adoc for build and install instructions and to the releases page for tarballs. A source build runs autogen.sh, then configure, make, and make install, with prefix defaulting to your home directory in the Makefile.

### How is Tig different from lazygit?

Tig is a viewer and pager layered over the git binary, while lazygit is a self-contained panel-driven application. The README frames Tig's pager role explicitly, which is the clearest statement of its design intent.

### Which version of Tig am I running, and what should I report with a bug?

Run tig -v to print the Tig and ncurses versions. The README's bug-report checklist asks for tig -v, uname -a, and git -v together, and directs reports to the issue tracker or the Git mailing list with tig in the subject.

## Sources

- [jonas/tig on GitHub](https://github.com/jonas/tig)
- [License: GPL-2.0](https://github.com/jonas/tig/blob/master/LICENSE)
- [Project website](https://jonas.github.io/tig/)
- [README](https://github.com/jonas/tig/blob/master/README.md)
- [Releases](https://github.com/jonas/tig/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jonas-tig