Git is powerful, and Github is its killer app. I use them for all my projects. That being said,
Git is more difficult than it ought to be, but until now I couldn’t put my finger on why
I was doing some mundane Linux command line work when I had my flash of insight. I’ve been using Linux for years, but I almost made a typical newbie mistake with the mv command. I wanted to rename a file:
mv /path/to/old_name new_name
Urp! I stopped, because this would not have just renamed the file, but moved it into my current directory as well. And then I recalled the typical mv tutorials which usually explain how the unix filesystem works, and how with that understanding, mv’s behavior makes sense.
In other words, mv combines two conceptual functions into one thing, simply because that’s the underlying implementation.
And I realized that this kind of “implementation leakage” occurs with many git commands. The non plus ultra evidence is the excellent post, Git Reset Demystified by Scott Chacon. It’s about git’s equivalent to svn revert — a very important function, undoing your changes. But even though Scott is very knowledgable about git and even authored the book, Pro Git, he
…never strongly understood the command beyond the handful of specific use cases that I needed it for. I knew what the command did, but not really how it was designed to work.
It’s no wonder that ordinary git users don’t fully grasp these commands. In a confirmation of my theory about git’s problems, Scott presents this 6×4 table as a learning aide:
A second example is the well written O’Reilly book Version Control with Git. It teaches the internal implementation of git before explaining how to fully use it. Or, as David Eisinger says,
…until you wrap your head around its internal model, it’s easy to wind up in a jumble of merge commits or worse.
Fixing git: two ideas
- The aptitude route. (Specifically, the command-line use.) Originally, one needed to remember to use apt-get install but switch to apt-cache search to look up packages, due to implementation details. Now, however, both functions are available via one high level command line interface, aptitude. Legit is the only one I’ve found so far and looks pretty good. I’ve begun writing up my own ideas about what a front-end would have as well.
- Git command aliases. Git supports the creation of new commands via its alias feature. This might not be a bad route, if it’s flexible enough. LOLA’s a great example.
See also
- A great related post: On git and usability
- Michael Feathers takes the opposite point of view: My Satisfaction with Git: No Abstraction.
Dogweather 
I, too, always feel one step away from breaking something when using git. The low-level nature of the commands leads to a perceived brittleness that always makes me feel nervous. Maybe the git UI is already the “best possible” in terms of an optimal interface to the underlying implementation, but I will watch with great interest your efforts on “g”!
Why are you starting a new project instead of switching/contributing to an existing git porcelain?
There are a lot out there: https://git.wiki.kernel.org/articles/i/n/t/Interfaces,_frontends,_and_tools.html and git-legit.org (which isn’t listed but I just found out about elsewhere)
Excellent – thanks for the link. I just found git-legit as well. It was a little difficult to find via google – although the only one I found for “command line git wrapper / front-end”.
Two Words: Machines and software are supposed to serve humans, not the other way around.
I agree that git porcelain very close to aptitude would be awesome. The problem is the 80/20 rule as described by Joel Spolsky … it is true 80% of your users only use 20% of the features … the rub is, it isn’t the same 20%.
That is what I think makes git wrappers so rough, because there are so many different working models built on top of git. You would write in the 20% of git you love and make it easily accessible via your wrapper, but it turns out, it misses the 3 key features I need — so I have to break though the illusion and use plain old git.
The reason I think the git console has continued to be successful is that once you use it for a few weeks, you establish your usage patterns and your domain, and you become very comfortable — but they are assuredly yours.
I see the same thing happen in Vim community, someone wants to simplify / better Vim by making a clone. They realize that no one uses all these crazy features — but when re-implementing, they learn everyone uses a different 2% of the features, so people are constantly unhappy with the new clone, because people have become very comfortable in there little vim workflows, in their unique 2%.
I think Git wrappers will be plagued with the same problems unless people learn Git via the wrapper — and then they are only exposed to the power the wrapper exposes, which in most cases will be a subset.
Thanks – interesting perspective. I’ll take another look at aptitude and see how they designed the CLI commands. It’s a successful app that can be learned from.
The problem with aptitude is exactly that: if I want to see which repositories provide a certain package, I still have to use «apt-cache policy» as «aptitutde versions» is essentially useless, or if I want to list the files in a package I must use «dpkg -L»
Personally I feel that Mercurial makes better trade-offs in power vs usability. But I’m still forced to deal with Git if I want to cooperate with the majority of developers out there.
My conclusion: the most annoying thing about Git is that everybody is using it 🙂
Mercurial was my “go to” system. Better support for windows, cleaner implementation, etc.
However, when I encountered Mercurial usage on teams… I was horrified. You can’t just use Mercurial, you have to use Mercurial + all the teams mercurial extensions.
To work on our project you just need Mercurial, then enable factotum, largefiles, mq, rebase, relink, transplant, win32text … ohh, and after you enable those, you have to download and install attic, buglink, commits, collapse, deps, fixcase, kerberos… goes on and on.
The plugin system and use means that the experience for users are Mercurial can vary vastly, and creates a big step in getting Mercurial up and running for a new member on a team.
Really? We tar.gz or zip (depending on platform) our extension configuration and extension content, and setup takes 3 seconds.
mercurial is pretty darn easy to set up. and even easier to clone a bunch of installed extensions from one person’s workstation to another.
Warren
I take the opposite viewpoint. I posted a blog response here: http://michaelfeathers.typepad.com/michael_feathers_blog/2012/04/my-satisfaction-with-git-no-abstraction.html
Nice post – adding a link to it. Thanks.