Tig: text-mode interface for Git(jonas.nitro.dk)
jonas.nitro.dk
Tig: text-mode interface for Git
http://jonas.nitro.dk/tig/
11 comments
I recently switched from vim to emacs (mostly cause I want to mess around with LISPs and emacs LISP support is good e.g. CIDER) and I've had my eye on Magit from the get go, haven't had the time to mess around with it yet but definitely looking forward to do that.
>The disadvantage, of course, is that one really should still know how to use git competently at the command line for the 15% of tasks such wrappers aren't good at.
I definitely agree with this. I always learn the core technology before learning any convenience layer/wrapper/abstraction e.g. {(git, Magit), (CSS, -Insert Grid Framework-)}.
>The disadvantage, of course, is that one really should still know how to use git competently at the command line for the 15% of tasks such wrappers aren't good at.
I definitely agree with this. I always learn the core technology before learning any convenience layer/wrapper/abstraction e.g. {(git, Magit), (CSS, -Insert Grid Framework-)}.
IMHO, Magit is easy to pick up and well worth the modest time investment. I have found the new release to be pretty speedy and making the commit directly from within Emacs is very handy.
Magit takes almost zero time to learn if you're used to the git CLI (some things are a bit weird, but mostly the commands are obvious from the help). It's basically a super-powered version of the git aliases lots of people use, but I don't bother, because I have magit :-)
Magit is amazing. Start using it now.
`C-h m` is your friend
`C-h m` is your friend
The `tig` blame mode is still vastly superior though. I find blame in magit (and magit-next) unusable, unfortunately.
I use the magit interface for most operations, but for blame I usually fall back to vc-annotate, as I find it easier to read (commits on the left rather than as headers, coloring, customizable).
I haven't used tig, but from the blame view screenshot [1], they may be similar.
[1] http://jonas.nitro.dk/tig/screenshots/blame-view.html
I haven't used tig, but from the blame view screenshot [1], they may be similar.
[1] http://jonas.nitro.dk/tig/screenshots/blame-view.html
I also use vc-annotate, but tig blame is still superior in terms of commit annotation (shorter, easier to customize, and commit-based coloring).
...and for the use-case where you're on a remote system with a slow connection it's feasible to run magit inside `emacs -nw`.
Use tramp from your local emacs
http://www.emacswiki.org/emacs/TrampMode
http://www.emacswiki.org/emacs/TrampMode
I use this tool quite a bit. It's pretty nice, especially when SSHing into remote systems that don't have any UI available, but you need to do work with git repositories.
It's the best text-based tool I've seen for quickly visualizing git histories and diffs for each commit.
It's the best text-based tool I've seen for quickly visualizing git histories and diffs for each commit.
I like it a bit more colourfull and have more space for the commit notes than for the author's name:
~/.tigrc
set git-colors = no
set show-changes = yes
set commit-order = topo
set refresh-mode = auto
set main-view = \
date:default \
author:abbreviated \
id:yes,color \
commit-title:graph=yes,refs=yesVery cool, I've been using tig all this time and never even bothered to realize it was customizable.
You might also enjoy ranger[0] which is a console file manager with vi key bindings, I use it as my primary file manager and it's pretty convenient when SSHing as well.
Edit: I should also clarify that if I will work with a remote directory for a non-trivial amount of operations or time, I just mount it locally via sshfs[1] which also saves me the pain of having to install ranger on the remote machine.
[0] https://news.ycombinator.com/item?id=10090834
[1] http://fuse.sourceforge.net/sshfs.html
Edit: I should also clarify that if I will work with a remote directory for a non-trivial amount of operations or time, I just mount it locally via sshfs[1] which also saves me the pain of having to install ranger on the remote machine.
[0] https://news.ycombinator.com/item?id=10090834
[1] http://fuse.sourceforge.net/sshfs.html
The one thing tig is really good for imo is the interactive log view with branch information etc.; it also loads asynchronously, so e.g. the Emacs repository will still take quite a while to load for all commits, but it's usable in the meantime.
Agree strongly. I find all the functionality unrelated to log exploration to be extraneous at best, and dangerous at worst, when a simple key press can actually make unexpected changes.
I'm perfectly comfortable on the command line for all the tasks except log exploration, where I find the interactive elements to be indispensable to prevent constant copying and pasting between log/diff/blame/show.
I'm perfectly comfortable on the command line for all the tasks except log exploration, where I find the interactive elements to be indispensable to prevent constant copying and pasting between log/diff/blame/show.
One of the nice things about tig is its configurability. I have this in my ~/.tigrc, which helps a lot with my workflow:
bind main R !git rebase -i %(commit)
bind main M !git merge --ff-only %(commit)I added that R binding a couple of months ago, and it is magical. I hated having to git log, copy the sha, and then 'git rebase -i [paste]' every time. I've mostly switched over to magit, but this is one thing I still use tig for.
For me, rebasing usually concerns roughly the last N commits, which is why I don't bother running `git rebase -i HEAD~N` and ignore and commits I don't want to modify.
Atlassian had a great blog post about tig that convinced me to start using it:
- https://blogs.atlassian.com/2013/05/git-tig/
- https://blogs.atlassian.com/2013/05/git-tig/
Maybe it is a problem of me, but can't really get to use a visual front-end or framework (like gitflow) for git.
It almost always feels (inferior|complicated|bloated) compared to vanilla command line usage.
It almost always feels (inferior|complicated|bloated) compared to vanilla command line usage.
A visual tree view of how commits relate to various branches are always useful, doubly so when you can browse the diffs for the commits "point-and-click" (or arrow-keys, in this case)
It would be nice to have pictures of the thing on the homepage... or anywhere linked. I had to find the atlassian link to even know what it looked like.
[EDIT] - I missed the folder called screenshots on the front page that has screenshots in it.
Also Magit, if you use emacs.
[EDIT] - I missed the folder called screenshots on the front page that has screenshots in it.
Also Magit, if you use emacs.
I use tig daily, it's so much faster to select the files/chunks/lines to add to the staging area than with the command line.
Staging view is quite useful and I spend a lot of time there too. Also, maybe because I haven't tried enough of the alternatives, I think tig does the best job of visualizing the commit graph.
If you use vim, fugitive is a pleasant and powerful wrapper for git.
To further expand on your comment, Tim Pope's Fugitive plugin is an almost exact replica of OP's tig program.
Fugitive allows you to perform almost all of these actions while still in Vim; I'd say it's almost a must-have for anyone who uses Vim and Git.
Fugitive allows you to perform almost all of these actions while still in Vim; I'd say it's almost a must-have for anyone who uses Vim and Git.
Use this often, it's great and neat.
I rely heavily on tig. highly recommended
Stuff like this is nice because it does let one directly manipulate objects within a git repository easily with a few keystrokes, rather than having to type 'git exchange-frobnozz --quark-handler=positronium' constantly (or having a million aliases, each of which is useful right up until it needs to be modified slightly).
The disadvantage, of course, is that one really should still know how to use git competently at the command line for the 15% of tasks such wrappers aren't good at.