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.
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.
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.
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.
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'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.
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 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.
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.
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.
> 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.
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.
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.
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
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.
97 comments
[ 4.0 ms ] story [ 161 ms ] threadtldr: 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.)
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.
[1] https://magit.vc/
To me the whole point of revision control is to examine who did what when and why.
That logs are useful is cool too.
It's quite fast and is easy to add it to your regular git flows.
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.
https://youtu.be/z0mb0NteYjg
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)
[1] https://i.stack.imgur.com/oD7mJ.png
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).
https://github.com/extrawurst/gitui
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.
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.
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.
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
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.