Tig – Text-mode interface for Git(jonas.github.io)
jonas.github.io
Tig – Text-mode interface for Git
https://jonas.github.io/tig/
97 comments
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.
curl -so ~/.tigrc 'https://raw.githubusercontent.com/cbertoldi/dotfiles/master/tigrc.symlink'tig along with htop, tmux, ag, and vim are always the first packages I install on any new host. They're indispensable.
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.
[1] https://magit.vc/
[1] https://magit.vc/
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.
To me the whole point of revision control is to examine who did what when and why.
Automated distributed versioned backups are no small feature.
That logs are useful is cool too.
That logs are useful is cool too.
same here also it's much faster to open when you have a really large repository
+1
Tig is awesome!
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.
text-mode interface for Git
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!
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!
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.
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.
magit is a good alternative, it's not exactly a TUI because it works entirely inside emacs
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).
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).
Interesting, thank you! I think I need go learn more about what "curses" means
"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.
[0] https://en.wikipedia.org/wiki/Curses_(programming_library)
[1] https://i.stack.imgur.com/oD7mJ.png
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)
[1] https://i.stack.imgur.com/oD7mJ.png
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.
Curses is just a library for writing command line interfaces.
You mean text user interfaces, right?
You mean text user interfaces, right?
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.
Interesting, thank you!
As a short analogy: ps vs. top
It provides a curses-based TUI, while generally git just provides a CLI.
Mandatory plug: https://magit.vc/
That's the first thing that drove me initially to Emacs. I never found a Git client that well-crafted.
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.
It's silly git nomenclature for "human readable output". Except it's not even used consistently within git.
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.
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.
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
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.
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.
And for Vim nerds: https://github.com/tpope/vim-fugitive
(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 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.)
There is also Vimagit, which is inspired by Magit: https://github.com/jreybert/vimagit
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.
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.
And also e (for edit) which, at least for me, opens vin for a quick change when needed.
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.
My favorite is lazygit: https://github.com/jesseduffield/lazygit
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.
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.
Uhm, you didn’t see the featured “Screenshots” item in the main navigation?
He did say "prominent". I agree, inline screenshots on the site are preferable to a Flickr gallery.
ditto but i downloaded it anyway and am very glad i did.
btw on mobile, the screenshots are hidden behind the hamburger menu at the top of the page.
btw on mobile, the screenshots are hidden behind the hamburger menu at the top of the page.
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.
Lazygit is an alternative that I like.
[deleted]
Second lazygit. My personal favorite at https://github.com/jesseduffield/lazygit
Started using lazygit a couple months ago and never looked back.
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.
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.
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.
fugitive + gv vim plugins
I’m a big fan of tpope’s fugitive: https://github.com/tpope/vim-fugitive
Not only is the name just three letters long, it's git backwards, and the acronym text-mode interface for git. Simply perfect.
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...
Tig is my favourite command-line Git interface.
Handy tip - you can enable mouse support by putting "set mouse = yes" in ~/.tigrc.
Handy tip - you can enable mouse support by putting "set mouse = yes" in ~/.tigrc.
In Poland in the 90s there was a spreadsheet application for DOS named TIG. It was a companion to word editor named TAG.
I use tig every day! Love it!
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
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
You can add your own binding for e or perhaps some other key:
[tig "bind"]
generic = e !script %(file)
cd `dirname $1`
vim `basename $1`
Been using tig for years and couldn’t imagine going back. I love how closely it maps to the standard git CLI.
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.
I just can't understand how all these people here use Git clients without a syntax highlighting.
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).
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).
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).
Are there any good TUIs for mercurial?
I have only found https://github.com/matheuslessarodrigues/verco which not as good as tig or lazygit
I have only found https://github.com/matheuslessarodrigues/verco which not as good as tig or lazygit
A timeless classic, have for years and will continue to use it daily
Related, I like https://github.com/jesseduffield/lazygit
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.
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.
Out of curiosity what's wrong with git add -i? That's what I use to stage parts of a file.
`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'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 is a better alternative
https://github.com/extrawurst/gitui
https://github.com/extrawurst/gitui
> 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.
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.
What is the main feature that makes Gutui better than Tig?
That is subjective. I have not warmed up to curses UIs that have window frames. YMMV.
I've been using Tig for years. It works, it works well, it is fast and mostly intuitive.
Usually people like it and want to use it after they see me using it.
Usually people like it and want to use it after they see me using it.
I use this quite a bit for ad-hoc git log viewing in bash. Thanks to the developers!
Why no pictures, I'd like to see it first without installing it to my machine.
bit is my latest favorite git TUI. Check it out here: https://github.com/chriswalz/bit
Love Tig, it's an instant go-to everyday for Getting Things Done™
Ahhh one of my fave command line utilities, super useful git tool.
I use it all time for years now, must have git companion
I've used `tig` for years and it's wonderful.
Do folks have .tigrc shortcuts they'd recommend?
tig seems like it could be a cool tool, but trying to view screenshots (on ios latest safari) left me stuck on a flickr login screen. ):
For what it's worth, I don't think the screenshots do it any favor.
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.
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.
See the video here
https://youtu.be/z0mb0NteYjg
https://youtu.be/z0mb0NteYjg
a simple video demo/gif would be really cool to see what it does in one glance
tig really is great, I've been using it for years now
I love tig.
Git already has a text-mode interface, its called Git!
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.