Tig – Text-mode interface for Git
jonas.github.io
jonas.github.io
It's handy to know that the arrow keys are used for browsing the log messages, while return followed by either pgup/pgdn or j/k are used for scrolling the contents of a log message. And it's easy to search logs with /.
Tig is also theme-able. For instance with:
curl -so ~/.tigrc 'https://raw.githubusercontent.com/cbertoldi/dotfiles/master/...'
Note that this may overwrite your ~/.tigrc, if you already have one. Colors are subjective, but I like how it looks in my terminal emulator.
Tig is highly recommended. It just works and is one less thing to worry about.
curl -so ~/.tigrc 'https://raw.githubusercontent.com/cbertoldi/dotfiles/master/tigrc.symlink'To me the whole point of revision control is to examine who did what when and why.
That logs are useful is cool too.
Based on the comments here saying they love Tig, I know I'm missing something, but: doesn't Git provide a text interface (the `git` command) to Git?
I'm not trying to be obtuse; I genuinely don't know what Tig provides that Git doesn't already do, but would love to know!
magit is a good alternative, it's not exactly a TUI because it works entirely inside emacs and uses emacs concepts, but it's entirely text-based.
With a normal CLI program, you essentially just output to STDOUT line by line. You type `git status`, and the git program basically does `print(status)`. Then you're back to your terminal and you type another command, git or otherwise.
A "curses" program renders fundamentally different. It's much more like how video games render. Every time it renders, it'll draw to the entire screen. You're not in an empty command line where you can type any command, rather you are "in" the application. Take a look at this screenshot [1]. You can imagine how pressing up/down keys might move which input is selected. If you want to get back to the normal terminal you have to quit the TUI application.
While not commonly thought of TUIs, generally vi/emacs/lynx/etc would all technically qualify (tho people might give you a strange look if you called them TUIs). To be clear, these do not use curses. They kind of predate curses and just wrote it manually. Curses is not a requirement ffor a TUI, but is by far the most common library to use when writing TUIs now-a-days.
[0] https://en.wikipedia.org/wiki/Curses_(programming_library)
You mean text user interfaces, right?
Emacs also has TUI (when running in the Linux terminal or run `emacs -nw') so magit should also has TUI (at least on GNU/Linux where I use Emacs on).
tldr: git low-level commands are considered API and called "plumbing" (eg `git cat-file`, `git upload-pack`), otoh stuff like `git push` is porcelain: it's an ui layer.
What the parent mean is that some tool rely on the human-oriented, potentially unstable output of git commands instead of using lower level layers.
(I tend to be using different editors most of the time, but haven't found a text editor Git integration better than either Magit or Fugitive.)
I use it both for simple things like a good looking commit log (the default view), but like especially how I can navigate into an old commit, hit t (for tree), and navigate and peek into the files available in that specific commit, hit b (for blame) to view which commit changed a particular row etc.
I like how all the different views play together into such useful workflows, and how, just like in vim, everything is available one mnemonic keystroke away. Hit h (for help) inside it to explore ... you will be surprised at the power of using these different views together in practice.
It has better layouts and shortcuts. I used Magit before, but hated to install Emacs only for such a small feature set. Lazygit is perfect when you want to manipulate a git repo quickly, but very similarly to Magit.
Maybe it's because I'm on mobile, but it's a bit hard to see.
btw on mobile, the screenshots are hidden behind the hamburger menu at the top of the page.
It's quite fast and is easy to add it to your regular git flows.
Having some vim-like keybindings in non-vim tools is nice, but it's always a far cry from being vim. And personally I find it incredibly annoying when I'm in something vim-like enough to establish "I'm in vim" expectations and not meet them once I start trying to use the thing like vim without restraint. I'm then put into this constant second guessing mode of "if this really were vim I'd do so and so, but should I just try it? maybe it'll do something really unexpected, time to RTFM? sigh." which is really unproductive and psychologically awful.
Especially when we're talking about dev tools like git integration, where the mental state is already going to be steeped well into text editor land, all the familiar vimisms are going to be hot in the habitual cache.
Does anyone know of anything tig-like that's implemented as a vim plugin one interacts with through regular vim windows? I wouldn't mind having an interactive list interface for tagging files to include in a `git commit -p` for instance, without leaving the editor.
Handy tip - you can enable mouse support by putting "set mouse = yes" in ~/.tigrc.
My one wish is that when you go to edit a file from the interface (by hitting e) is that it would keep you in the directory you're in rather than editing the file as if you're in git root. Linters and other things break when I edit files from the root directory in our mono repo
[tig "bind"]
generic = e !script %(file)
cd `dirname $1`
vim `basename $1`
Screenshots are super important for projects imo to quickly understand how something is actually useful. Should always make the small effort to add an example GIF or image (if applicable to the project).
I've been a user for 8 years, but I only use it for viewing. Editing a repository remains a task exclusively for the CLI (or, occasionally, with magit).
I have only found https://github.com/matheuslessarodrigues/verco which not as good as tig or lazygit
Only since I use tig I understand how to commit hunks. It's super easy to split the changes of a file into different commits that make sense. With most other clients this is either cumbersome or not possible. So your forced to always commit all changes of a file in one commit.
I guess it just really works great for my workflow and the way I think about my repositories/commits.
I've used Tig daily for years (about ten) and basically use it for for quickly browsing the log and changing what's staged - probably less than 5% of its features.
Everything else I do via the command line with ZSH's excellent git completion.
Hardly a better alternative if it doesn't have all the basic features.
Usually people like it and want to use it after they see me using it.
The main thing is that it's a terminal-based git client with Vim bindings, and customization. It's hard to represent that in screenshots :)
But I've also been using it for years and it's working perfectly for me.