The strange git love of the command line

Git users love of the command line

 Why do a vast majority of git users love the command line so fervently? And why do I care?

Git is a great tool, but like said of "C", it's like a sharp knife. Excellent in the hands of an expert, but easy to cut your fingers if you're not.

Using git inexpertly can get you into all kinds of difficult-to-get-out trouble. Most developers' main job is to code, not maintain super-complex repositories with 100s or 1000s of contributors. You'd think they would welcome any tool that made the use of git easier and safer, perhaps forgoing some complex scenarios.

But, sorry to say, nope. Almost all of the developers I know and work with use git from the bash command line. It's also the only thing they use from bash, or any command line. Git has a zillion commands and options, but 9 out of 10 days the only things we do are:

• Pull updates from the remote.
• Create feature branches.
• Commit changes locally.
• Push changes to the remote.
• Stash changes temporarily locally.
• Switch branch.
• Merge branches.
• Rebase feature branches.
• Inspect the commit history of a file.

There are excellent graphical user interface frontends for git, in all environments. I'm on Windows, and I happen to be fond of TortoiseGit, but there are others.

The great thing about these tools are that for one, they are 100% compatible with each other and the command line, since they all use the same underlying implementation of git.

Nobody, not even the most hard-core developers, use a command line editor or a command line debugger for day-to-day development. We're simply more productive with graphical full screen integrated development environments like Visual Studio, and less prone to mistakes. There's a reason we're not using TECO any more, even if it was awesome in it's time and still is in some ways - I loved it!

The same applies to source code control. It's simply faster, more convenient and less error-prone to use a tool that integrates with your graphical environment be it Visual Studio or Explorer or whatever your local equivalent is.

But, for some strange weird reason - for git suddenly it must be done from the bash prompt. I try to explain, I try to show, but the command line fixation remains. Git from the command line users repeatedly get into trouble and have to reset their local repository clones. Command line users frequently take much longer to investigate history inspections, and also often just skip doing things like rebasing the feature branch before merge to the main development branch causing the commit history to become much more complex. Just because it's too complicated to do from the command line.

Still, they persist.

I get that there are some rare cases that the command line is needed. I get that for batch operations, such as merging a bunch of repositories from perhaps the development branch to the main branch a script using the command line is perfect.

But the command line is not gone just because you use a modern tool for day-to-day use. It's still there when you need it.

Why do young gifted competent developers insist on using a tool model that originates in the 60's when there are so many better alternatives - and in all other cases they do?

I don't get it. But it is a problem, because it affects productivity both directly in daily use and indirectly because it tends to cause more complex commit histories to untangle in the future.