Git? tig
blogs.atlassian.com
blogs.atlassian.com
I will give SourceTree a try, it looks interesting.
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.
[EDIT] And a few minutes of surfing told me that it requires .NET 4.5
However, for some things I still prefer fugitive, if only because it's right there in vim :)
Acquisitions have a way of rolling up technical debt.
Also, here's the manual: http://jonas.nitro.dk/tig/manual.html
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).
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:
(I'm also an emacs user/addict, but I would say "slow" is often a word I associate with it, alas...)
- 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)
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 :)
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.
https://github.com/dandavison/magit/commit/a969463ff30e5e248...
[Edited for links] Fugitive: https://github.com/tpope/vim-fugitive
Some helpful screencasts can be found here between April and May 2011 http://vimcasts.org/episodes/archive
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.
Atlassian blogged about it.
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.
[1] https://github.com/tpope/vim-fugitive [2] https://github.com/gregsexton/gitv
[pretty]
whatever = "tformat:%Cred%h%Creset -%C(yellow)%d %Creset%s %Cgreen(%an %cr)%Creset"
--pretty=whatever port install tig
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.
Apple has a habit of not updating the libraries in Mac OS X until absolutely necessitated by a security vulnerability.
https://trac.macports.org/wiki/FAQ#ownlibs
One other reason I use MacPorts is because I didn't like the idea of HB changing permissions of /usr/local:
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.
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.
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.
What's wrong with that?
it is the mutt to your Outlook, the Vim to your Emacs, the w3m to your Firefox.
Not sure I can follow?!
Not speaking for the author, but Tcl/Tk apps tend to be ugly. I use gitk from time to time, but it's ugly and has some usability problems.
> Not sure I can follow?!
Mutt is a terminal-based MUA. Where Outlook is a giant monstrosity of a mail client, mutt is fast and tiny.
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.
w3m is a terminal-based browser. In comparison, firefox is a slow, giant, memory sucking graphical browser.
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.
That's why I wasn't sure I could follow :-)
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.
I have been using it as a direct replacement for git log, and its something that gets installed on any system I work on for any length of time.
I would consider this: https://news.ycombinator.com/item?id=5667935 to be a good example of why that can be useful, no?
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)
http://www.gnu.org/software/emacs/manual/html_node/emacs/Ver...
$ brew install tigIt's just burning my eyes with blue and magenta colors :)
I showed it to my boss and he told me I should've been born 20 years earlier (born in '91).
I'd like to convert myself to git though.