There seems to be some confusion here in the comments. Atlassian did not make tig, Jonas Fonseca (https://github.com/jonas) did. In some sense though, it makes Atlassian even more awesome that they wrote a blog post about a piece of software they didn't create.
I noticed that as well. If anything, it earns my respect. It shows that Atlassian, and the developers behind their products, realize that everyone has different needs. That a single tool can't solve everything for everyone. I also think it means that the tools they do build will be better, because instead of trying to include the kitchen sink, each tool has an opinion on how to best achieve what it's trying to achieve.
Tower really helped me when I first started using git. Eventually I would move to the terminal, but still use Twoer for when I messed up or tried to do something more advanced.
I wish there was something just like it for Linux, all the ones I've found to try always have some strange UI, or something that just doesn't work quite 'right' in my mind.
I do a mix of cli and GUI for git interactions (since I do a limited number currently). Sourcetree has proven to be pretty decent on both windows and osx for me. One aspect I like about the windows version is that it uses Putty (specifically Pagent) which acts much like ssh-agent does on *nix system. Much nicer answer to key management compared to other Git UIs for windows that use OpenSSH.
While it looks similar, it became a lot more stable and far faster. I'm using Sourcetree for many things nowadays that I previously did solely on the cli simply because it works a lot better now than it worked just a year ago.
However, for some things I still prefer fugitive, if only because it's right there in vim :)
Looks cool! One little nitpick: "Vim to your Emacs"... Er, maybe Vim to your Eclipse. I don't know if I'd put Emacs in the same camp as Firefox or (heaven forbid) Outlook.
Yeah, that makes sense. It would have been a better troll/joke if he had said xemacs. I was honestly suggesting a better comparison, not suggesting it was a bad idea. ;-)
The two are not mutually exclusive. "A troll is someone who posts inflammatory, or off-topic messages [...], with the primary intent of provoking readers into an emotional response." [1]
Fugitive is hugely useful and actually provides features above and beyond tig.
That said, tig has an innate simplicity that works for people who are not native vim-ers.
I primarily use screen windows for different functionality. While I can accomplish everything from vim-fugitive, I still maintain a "git" window purely for mind-segmentation and window-SRP reasons.
Thus, tig may open up a completely new concept of active git interfacing.
That said, it is yet another keystroke set to remember (albeit a small keyset).
To be honest, fugitive is one level below Magit -- but it's still a must-have. On a side note, I think that not having an interface to Git is a show-stopper for a programming-oriented text editor, just like integrated compilation support. I checked TextAdapt lately, and I was surprised it doesn't have it (yet) (unless I'm mistaken).
Agreed. Fugitive rocks. I use it more than I do the command line. However I've never been happy with its ability to review history.
tig is one way to cover that gap, but I wanted to do my git log viewing in vim so I can more easily cut and paste. I wrote this git log viewer (vim plugin) to cover that gap:
Seconded, only my addiction of choice is egg, a fork of magit. It's blazingly fast, as well. Not sure what people have to put up with in other IDEs, and quite frankly, I don't care; that's why I use Emacs . . .
Sorry, I should have clarified; AFAIK, egg is not faster than magit, but I haven't really played with magit. My comment on speed was aimed at the article complaining about slow IDEs as git interfaces. When I run emacs, "slow" isn't the word that comes to mind, especially when compared to other IDEs (and I'm talking about with all sorts of IDE-type features added on to emacs). Egg is pretty fast, though.
That's not true for me. I'm forced to use older computers and/or virtual machines over overloaded networks. I had to recompile Emacs with -O3 and other optimization switches to get barely decent performance on the latest versions of Emacs. That's why I've switching a lot between Emacs and Vim recently.
Honestly, I think you need to check your distro's emacs setup. Most of the time the crappy slowness comes from all kinds of badly written elisp modules that you really don't need (which is the wrong way to do it anyway). If you just load the pure emacs image, it's VERY zippy.
I'm not so sure; people keep adding stuff to emacs, and performance doesn't really seem to be a priority. To give a couple examples off the top of my head:
- A recent version of emacs changed the default shell history command to show live search results (like bash does), but the emacs implementation was ungodly slow if your bash history was longer than a few dozen items (waaay slower than a real terminal interactive bash search). Moreover, it completely locked up emacs while doing the search (since emacs is single-threaded and synchronous). After the suffering got high enough, I finally tracked down how to revert to the old behavior.
- The latest emacs python mode for some unknown reason would freeze for like 10 seconds when opening certain python files. Rather than track it down, I went back to using the latest python-people python mode (for some reason, the emacs people insist on writing their own python mode, rather than using the one the python people wrote). The python-people python mode doesn't lock up, but narrow-to-defun takes maybe 300ms (not terrible, but clunky feeling; way worse than instant), for some reason.
- Or check out this awesome, high-performance code from the function comint-exec:
;; Feed it the startfile.
(cond (startfile
;;This is guaranteed to wait long enough
;;but has bad results if the comint does not prompt at all
;; (while (= size (buffer-size))
;; (sleep-for 1))
;;I hope 1 second is enough!
(sleep-for 1)
(goto-char (point-max))
(insert-file-contents startfile)
See that sleep-for? That's an awesome built 1-second pause while waiting, for example, for an emacs shell to startup if you have a custom .emacs_bash defined.
There's lots more stuff like this. Emacs is a giant ball of elisp mud that's perpetually half-broken, half-implemented, or slow...but it's still the best thing going, by more flexible and more useful than any other editor out there (AFAIK).
But I'm not convinced it isn't possible to do something as flexible as emacs without all the random breakage and general lack of concern for performance. Think maybe replace elisp with LuaJIT, and take cultural inspiration from the make-it-fast ethos of git and the make-it-correct ethos of sqlite. Something like that.
Oh, and also, unlike every modern day attempt at an editor, it should still support running in a terminal, because terminals are still damn useful.
So yeah, could someone get on that please? Thanks :)
Emacs could gain a lot of performance boosts with some significant changes to its architecture. It would be a lot of work to do and doing so requires a set of skills that are much less available than other software engineering skills unfortunately. I am hoping either that occurs or there exists a viable replacement for Emacs that incorporates the improvements more easily due to starting with a blank slate.
Proprietary programs are a deal breaker for me as far as contributing to them in my free time a great deal due to how frequent they go out of business and lose support. So, a new iteration of Emacs would require a very free license for me to have confidence that my efforts won't be wasted in a short period later.
I am hoping that Light Table is released with a license and degree of openness that provides a similar degree of hackability as the Emacs platform does. If that happens I think I will make a lot of effort to bring it up to speed with features Emacs has but Light Table doesn't at the time.
Chris Granger has made a lot of smart design decisions that really appeal to me about Light Table. His point in one presentation that while Emacs and VIM are fantastic at text related operations, there doesn't exist something comparable that has both great support for text and great support for visualization.
That is a thought that really resonates with me. Having fantastic graphing capabilities and embedding of graphic tools such that the work flow can exploit both graphics manipulations and text operations would be a huge boost in capabilities, something which adding to Emacs would be much harder due to so much legacy code in the platform that will have to be accommodated in the process.
As an example, people have really wanted to move Emacs underlying language from elisp to common lisp for a long time, but it is such a massive undertaking and transitioning the community to using it would be so difficult that (without a team to work on it constantly) no one has succeeded in doing so fully.
Light Table's decision to use any language which can compile to javascript as its backend and use node-webkit as its front end results in a lot of features that are free in the process that are very nice to have for tool building.
And Granger has made a point to customize the compilers for the languages it supports to glean even more information and manipulation of the languages in the process, something which I hope is kept up as its support expands.
I absolutely love its instarepl design that is motivated by his idea of real time debugging. Combining that with Crockford's context or scope based coloring concept would be a massively useful feature set for development and tools to be able to exploit. The scope based coloring isn't something that Light Table has already or something Granger has mentioned adding, but it is something I hope enthusiasts can add assuming the platform is sufficiently extensible.
Granger's earlier idea of breaking down the environment based on functions as the smallest unit of focus instead of a file is another brilliant design concept that will be available in the future (according to another presentation he did).
So, I am very excited about its potential as a replacement for Emacs that takes that idea and makes it even better based on adding modern developments, and Granger seems to really appreciate open source and has a willingness to contribute towards that.
So, I am hoping that somehow the Light Table team is able to both charge for the tool and make it fully extensible as well as remove the potential for abandonment of the platform to result in a volunteer's effort being wasted, such as fully porting SLIME (a very exceptional lisp development environment that emacs has) to Light Table as well as ESS (a statistics development environment which could benefit from more graphics potential being available) that emacs has.
I think Light Table will already be a killer app for REPL centric platforms by the 1.0 release, and languages which have excellent REPL support and debugging is what I mainly use already. Adding the other features I mentioned will make it unquestionably the new state of the art for that context.
I love magit. I think magit-status is probably the most used command in my emacs log. Or at least the most used buffer. What I like most is that it doesn't try to simplify or hide git's workflow too much like some other gui's do.
The description of the status display is almost exactly what happens when you type ":Gstatus" while you are editing a file under a git repository in vim, if you have the fugitive plugin installed. If you use vim, you might be interested in this - there is some extra smoothness you get when you don't have to leave your editor.
Yup, came here to second this recommendation. A lot of the benefits found in tig can be found in fugitive. One feature of fugitive I use all the time is Gdiff to allow quick and easy comparison of various versions of a file. Nonetheless, the history view and other features of tig are worth checking out.
I use tig and fugitive for about one year and a half, now, and I must say that even if fuvitive seems more powerful to me in its ability to let you see old versions of a file in your editor, I use tig on regular basis, and fugitive very rarely. they're user experience just doesn't match.
Nice, Atlassian continues to make my job much much easier in regards to Git. I love the work they've done on SourceTree, which was a promising and pretty app but very unstable before they bought it. It was hard to use it for critical work because it was crashing quite frequently. Now it's rock solid and I use it almost every day. I do know most of the command line tools but I like using a GUI because it makes my repo better when I have a visual overview of everything that's going on. It helps me group commits in logical order and I've reduced the amount of basically meaningless fixes and style commits greatly.
I'd never even heard of Tig but I am already in love after about 5 minutes of usage. I'm comfortable with the Git CL and if you toss Git log enough flags, it gives you a very nice printout, but you can't actually DO anything there. This is a nice solution when you're working on a remote server but I'd also bet that if SourceTree is not open, I'm going to find myself more and more dropping into Tig rather than using SourceTree.
Otherwise, tig is neat.
I personally won't have to do `git lga` + copy commit's SHA1 + `git show COPIED_SHA1` anymore.
The thing it lacks imo, is more VI-style shortcuts (such as "gg" and "G"), displaying the SHA1 of each commit, and a feature to copy the hash of a specific commit.
Fellow Mac user here... Have you tried homebrew? I had been using MacPorts until someone told me "Homebrew is far faster." And indeed, installing something on MP takes me ages, while on homebrew it's a matter of seconds
HB may have changed this in the last couple years but I haven't bothered looking over the fence: MP has been near bulletproof for me, and has provided nearly everything relevant that I've needed.
I really like that aspect of homebrew. I don't let anything else use /usr/local, and it means I can install things without using sudo, so no risk they are messing something up elsewhere in system directories.
But you risk the installation messing with your data and home directory. MacPorts uses sudo because it drops privileges to a specific 'macports' user for the build process and applies sandboxing. Therefore, the execution of Makefile rules and other build scripts cannot harm your data.
I remember when I upgraded to Lion everything got messed up. I had to spend a whole day mucking about trying to fix thing. I remember the only solution was to get a list of everything installed, uninstall everything, reinstall the latest version of MacPorts and then reinstall all the original packages.
Migration is still required to reinstall ports as the underlying system libraries change on a major version upgrade of Mac OS X.
However, situation still improved a lot since then. If the licensing of the port and all dependencies allow it, MacPorts now even offers pre-compiled binary archives for Snow Leopard, Lion and Mountain Lion. Often you do not even have to compile software yourself anymore.
No fussing around with your mouse, or alt-tabbing to another window, or waiting for a JVM to start. It’s there at your fingertips whenever you need it. It literally loads the 50,000 commits of the JIRA codebase in a fraction of a second.
And:
In short, it is the mutt to your Outlook, the Vim to your Emacs, the w3m to your Firefox.
The author doesn't like that it is written in tcl/tk. I have no idea how this would matter at all unless he plans on modifying the source. I happen to like gitk and use it often. What language it's implemented is of little concern to me. At one time I used tig(it is pretty old at this point), but it never really caught on for me. Perhaps I didn't give it enough of a chane, perhaps it's much better now.
Is there any reason SmartGit doesn't get more love? I've been using it for over a year now and much prefer it over every other git client I've ever used (and I've tried a lot)
http://www.syntevo.com/smartgithg/index.html
I haven't tried most of the alternatives mentioned on this page. I primarily use:
[a] the command line.
[b] git gui, (occasionally) for reviewing commits.
[c] meld, for all merge and diff-related tasks.
[d] gitk, pretty much only for viewing the history of a specific file.
[e] SmartGit, for cherry-picking and anything more complicated than my memory can handle.
There are very few times that I would not prefer using a GUI, when the alternative would be typing all or part of a hash. The hash is for machine consumption, not human consumption: let the machine deal with it. To that particular end, I have found SmartGit to be excellent, and would recommend it.
Re: complaints about GUI tools: Someone is going to have to tell me why you would be using git via a remote ssh session instead of having a local copy. I am sure there is a logical scenario for that.
I am using tig all the time, really convenient, I share sentiment of the author, command line is most convenient. I do use Vim and awesome Tim Pope Fugitive for blame and such operations. I am glad this information is publicized.
Vim is [can be] a terminal-based text editor. The claim here is that emacs is big, ugly, and slow and vim is smaller & faster.
Ahem.
Not to start any flame wars, but Emacs can be run inside a terminal as well. As a matter of fact, that's the only way I run it.
"Ugly" is a matter of opinion for sure, as beauty lies in the eye of the beholder. Emacs can (and does) make use of terminal colors, fonts are freely configurable. I can't think of anything else that would be relevant for a text editor, except of course if by "ugly" you refer to its architecture, editing model, or something like that, rather than its appearance. If not, Emacs 24 allows you to install your favorite color scheme (solarized, zenburn, dawn, etc.) right through the built-in package manager.
Re: "fast" - Emacs does not show any perceivable lag in everyday use, and my main computer these days is an old netbook. Still, Emacs feels fully reactive. If you refer, however, to startup times, then you may not be aware of the 'emacsclient' feature, which is the way a lot of serious Emacs users run their editor. You basically start an emacs daemon to which you then connect with thin interface clients, but I don't even feel the need for it, possibly because the usage model for Emacs is different from Vim: I usually open one editor window on a dedicated virtual desktop that stays open all the time, and where I live most of the time, while with Vim, people tend to quickly open a couple of instances in parallel. (Maybe these patterns have established themselves in the olden times where Vim clearly outpaced Emacs in terms of startup times, i.e., on older machines, and before 'emacsclient'.)
But you're certainly right about "smaller". As I said, I'm using an old netbook most of the time, but even on this limited machine, Emacs does not take up considerable disk space. Times have changed, and disks have grown. As for RAM, I've never noticed it, the hogs are usually others (I'm looking at you, Firefox!).
Vim is nice and small that you can install it even on very limited disk space, say on your stone-old mobile phone. (Enjoy using it there, too.) But that's not a typical scenario any more, diskspace is not longer an issue in modern computing, at least as long as we're talking about text editing..
I would still say that Vim has one great advantage over Emacs, namely that it is pretty much ubiquitous. You can log in to pretty much any server, and you can be quite sure that there's some variety of vi installed. That's really great. But if that was something the author of the original post referred to with his "analogy" is questionable.
Long-time emacs user here ... I was trying to explain the context of the quote. I used "The claim here" to avoid making the statement myself and simply explain the comparison.
Cool. Makes life easy. Accessing all info on command line is awesome. History/Diff view is best thing about it. Thanks for sharing. I see myself using it on daily basis.
i too like the fact that the makers of sourcetree write about it.
I've been using tig since the very first version. I have tried to find something similar for mercurial without luck. it's probably one of the main reasons why i prefer git over mercurial (usability wise anyway)
Oh, I was looking for something like this today. Gitk is all well and good, but I have a whole heap of commands all tied into a custom Menu for Komodo Edit. I hope `tig' can work in it's output pane: it'll be a lifesaver if it does!
