Tig is and has been my favorite utility for browsing git logs for years now. Thanks tig developers and contributors!
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 /.
I will also say tig is awesome. I use it all the time and have submitted a few PRs to it for my particular idiosyncrasies. Vim's gv plugin is also good.
How often do you browse git logs? I see others also mentioning using git logs, but I really myself have not used it very often except maybe in some very edge cases and it is hard for me to imagine when it might be useful.
I think this might be one of those cases where improving the ergonomics of it greatly affects this sort of thing.
I use magit[1] on emacs and I can pull up logs with 1-2 actions, and when used with a split-pane setup, navigating the logs on one pane (with keyboard-based navigation) instantly displays the commit (message and diffs) on the other pane.
So I browse logs on an almost daily basis---not just of my colleagues' commits when I'm trying to familiarize myself with what's moved in the meantime, but also my own commits.
Interesting comment!
If one doesn't use the history part of revision control, why bother with revision control at all? Serious question.
One could just do backups and skip the overhead of revision control.
To me the whole point of revision control is to examine who did what when and why.
I'd like to just say that Tig has been deeply integrated into my terminal git workflow for so many years, it's one of the first things I install on any new system. I've found that practically all GUIs for git only serve to be a shell for the same commands you'd be quicker typing out in the first place, and their only unique value is a visual representation your branching and the ability to quickly stage/unstage chunks of code within a file. Tig brings these two tasks beautifully into any command line workflow, loading instantly and having good keyboard shortcuts <3
I'll have to try it and see how it compares to Magit. Magit is by far my favorite way to interact with git. I do work on a repo currently however that brings Magit to its knees performance-wise, so I'll have to see if Tig performs better with it.
tig is a curses program, it's an interactive terminal GUI (a TUI), as opposed to a CLI e.g. you can browse and interact with your log rather than dump it in a pager and need a separate terminal to dive into a commit or whatever.
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.
"Curses" is a library for writing, well, TUIs[0]. I get that's a bit circular, so let me explain.
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.
Actually, curses uses two buffers and diffs them so that only the delta is sent „over the wire“. In graphics, everything is redrawn every frame usually.
Curses is just a library for writing command line interfaces. Normally a CLI just deals with the text buffer pushing content and the user inputting textual commands, curses allows for a bit more control like with panes, dynamic areas and giving the user more control on how to input commands.
Tig provides a GUI that is text-based, i.e. runs right in your terminal. It's essentially a shell friendly version of sourcetree/tortoisegit etc. A great tool on its own, but particularly useful for headless servers/remote machines.
That's because most aren't designed as git porcelains. Magit enhances and, in some cases, replaces git's abstractions with its own. If a git frontend starts by taking git's own built-in porcelain as a given then it's already doomed to failure.
I've been using Magit for years, but I've never seen the use of "porcelain" as a jargon term to describe anything but Magit. Can you point me to a 'splaner on the use of that term? Googling hasn't gotten me anything but an insight to just how many people take porcelain (the pottery) very, very seriously.
It's a git specific terminology. The plumbing is low level stuff like creating objects etc (ie. DAG operations). The porcelain is high level stuff like "rebase" which is (supposedly) designed for human use.
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.
Tig is one of the most valuable hidden gems out there.
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 uses whatever git's core.editor option tells it to, and supports setting $GIT_EDITOR to override it. I rely on that from time to time instead of having to write a bunch of different aliases in to my tig config for different editors.
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.
Excited to try this. I work in this one massive repo that Magit just can't handle. Pulling up the Magit status window takes 15-25 seconds on a 2019 15" MBP with an 8-core i9. It's torture because I'm so used to Magit that I hate having to change my workflow for one repo. I hope lazygit is faster than Magit.
I did not find any obvious screenshots in action when clicking around on the site. So, I won't bother investigating further. Maybe others would also like some prominent screenshots that show off why we may want to use/try this.
I've been using tig a lot recently; I've always just used git from the command line, but if you're working with a number of files, tig is hard to beat when you learn a few of the hotkeys.
I'm a huge fan of tig. It maps really well to my way of thinking about git repos and it is super quick way to see the graph of everything that's going on. In the Top 5 of command line tools for me.
I've been using it for I think well over a year now. Started with using it just to add/remove files from staging. Used git for everything else. Slowly added committing, pushing, creating patches, seeing history, ...
It's quite fast and is easy to add it to your regular git flows.
As a longtime vim user it feels like if I actually wanted a TUI veneer over the git CLI I'm already quite familiar with, I'd prefer it be done within vim as an extension/plugin or something.
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.
Check out vim's `:terminal` and `:vertical terminal` commands. It uses vim's window split management to place an ordinary no-kidding pty-based terminal into the vim UI. Ctrl-W N goes to Normal mode for copy (but not paste), Ctrl-W <motion> moves around like normal.
This is automatically installed when you install git on Windows, very good tool. The guy who wrote that piece of code that draws how the different branches are connected should receive some kind of award...
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 is so useful for Vimmer since some of key binds are the same with Vim.
Also, it's easier to execute rebase, cherry pick or all of git's commands than plane git commands if you customize it.
I have no idea why all people who are familiar with CLI don't use it.
Really, do you have to link screenshots separately to a flickr page?
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).
Does anyone here actually use tig to interact with Git repositories, rather than simply as a repository viewer?
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).
Using it for years. Pretty good and it's even included in the latest versions of git for windows (if you can't use something else, as it was my case for a while)
tig is great, it's my go-to git client on all my machines.
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.
`git add -i` is linear, you have to address files and chunks in order (there are workarounds for this, but they're clumsy). `git add -i` is a bit like using a typewriter, whereas `tig`, which lets you address files and chunks non-linearly, is like using a word processor by comparison. Edit to your hearts content.
Tig is just faster, staging and unstaging take a fraction of a second.
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.
I like tig, then I discovered lazygit, a samish idea in Go which as far as I can tell is more powerful and easier to use. (I have no affiliation to any).
> gitui currently lacks essential features in git like push, pull, and checkout. The priorities are the basics (add, commit), and on features that are making me mad when done on the git shell, like stashes and hunks.
Hardly a better alternative if it doesn't have all the basic features.
I’ve been using tig for years and never did a push / pull / checkout with it. The git CLI works fine for that, so I understand the authors priority here.
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.