For people that use them a lot, smart text-based UIs can be much faster than GUIs (yes, even in 2012). Having the drag around the mouse and click eventually becomes cumbersome as well. But in the end it comes down to preference, I guess.
I agree with you - every time I see some new fancy GIT shell, and all the accoutrements that must be set up in the shell to get some sort of 'application intelligent integrated development shell' I feel like its 1983 and we're building GUI's with ANSI all over again.
Of course, I'm insanely jealous of these git'ologists with their fancy shells .. I'd love to have the patience to sit down and learn their wizardry .. but in the meantime, plain ol' git needs to be learned, can be learned, and doesn't require arcane insertions into ones .bashrc before one can be productive. Nice to see it, but no thanks: I'll stay plain, just coz.
Just the idea that the installation of an "app development environment" starts with modifying my bashrc, and thus my entire shell, bothers me. This may not be a rational fear, but as a crufty old Unix guy, it a 'smell' to me.
Its just not clean - there are too many opportunities to have something end up in there that breaks something else. My .bashrc is not an /etc.
I know, I know .. there is no other way to have a fully super-duper shell environment with pretty colors and notifications and other .. GUI-like elements .. without tweaking my prompts and touching my vars and so on. But, hey .. couldn't the same concept be built up as a real application, after all, which spawns its own shell and leaves my system defaults alone ..
it would be relatively easy (and I'd be surprised if someone hadn't scripted it to make it easier) to have a set of project specific configs which you merge into your global configs and exec a subshell per project. If you did it inside screen/tmux then you'd be able to switch between them easily as well.
The main issue I have with discriminating shells like this is that I tend to have a whole bunch open, and use the first I find that isn't already doing something useful. This means a lot of the time it's using features that technically 'belong' to a different project.
Yes, fair point. That's a good argument for using the git-number plugin instead, which has similar core features. The scm_breeze plugin didn't seem to like my hostile Cygwin environment, I'll try out git-number tomorrow, it should be a bit easier to get working. At first I was put off because I didn't know where it was putting its state. I see now that it is a text file in the .git directory, which on reflection is neater than the environment variables scm_breeze uses.
