* It's fast.
* It's there in the terminal, right where you're using git.
* Hence, easy to use over ssh :)
* Familiar keyboard shortcuts (press 'h' for help).
* Combined log/diff view, where each scrolls independently.
* 'tig --all'
I've often wished I could use it to start a rebase, but besides that, I find it damn near perfect.
The reason for lack of tests I see most often is that cost of set up (before writing any tests) can be high. This is especially true for inexperienced developers, and people using new technology stacks.
Setting up unit tests is (in my experience) considerably cheaper than setting up integration tests. And it's cheaper to set up a test framework for a project when you've already done so for a similar project, but the time spent learning the required techniques might've put management off allowing time for testing.
For example, consider writing an Eclipse plugin. It's very easy to get a plugin started; there's a template to get you going. But there's no template for a project that will run UI tests with SWTBot. Instead, you have an uphill battle. Create a new project; find the magic incantation to run such tests; realise it's not quite applicable to your project; set up a headless X server on the CI server; learn the test API. It's hard to explain how long all these small things take to someone who's never tried it.
The effort is certainly worth it, but it can be very difficult to justify the spending time on familiarisation and integration of a test framework. It depends on the company, of course. It's good to work somewhere where testing is considered part of software development. Others are more short-sighted.
I think lack of testing is part of a more general problem of not wanting to invest in improving skills and processes, because it doesn't align with short-term goals.
A lot of the discussion seems to assume that a given developer has a constant level of productivity and hence, can be salaried according to that level.
I'd say a developer's productivity can vary according to motivation; who they're working with; how interesting the work is; whether they're well managed or not...
So, while salary is a linear measure, it makes no sense to me to assume that productivity can be measured the same way.
I'm fairly sure my own productivity can vary by as much as an order of magnitude according to circumstances. Wonder what I should be getting paid? :)
If tig started "git rebase" (with or without -i) and then helped me through fixing any conflicts (merge tool?), that'd be awesome.
I sometimes forget where I am during a rebase, so showing how many more commits to go would be cool.