« The Tyranny of the Diff | Main | Type Driven Development »

April 26, 2012



+1 all the way.

Donald Norman (in "The Design of Everyday Things") makes a big deal about this very thing; calling it a "conceptual model."

A decent image appears partway through his blog post here:

Scott Jacobsen

Good points. I always tell people to read http://eagain.net/articles/git-for-computer-scientists/ when they don't grok something about the git CLI.

James Manning

The model that I think has worked well for some products (although targeting a different demographic/userbase) is something like what Microsoft Exchange does (bear with me, here ... :)

It comes with a GUI that both walks you through common tasks and helps visualize the current state of the system. However, when doing so, it lets you see how it's performing those actions (well, at least on the 'write' paths) by using the cmdlets that it comes with and showing you the 'script' that it wrote and will run.

Back when I admin'd bunches of AIX machines, there was a similar UI called 'smit' (and a tty version 'smitty') which similarly gave you a UI, but let you progressively learn the underlying details by constantly showing you what it was doing.

For people coming from another VCS (especially with no previous DVCS experience), I think a huge amount of clarity could be gained by just having visualization app(s) that showed you the current state of things (your local branches, remotes, etc.), especially if it could do so with 'potential changes' made (what do the various trees look like if I were to do command X?) without requiring manual use of stash and the like. :)

The bigger gain will certainly be when a UI lets you choose an 'action' entry of 'revert my local changes' but tells you what it's doing (as git commands) and why.

Of course, maybe the real answer is that there needs to be a new VCS created that just happens to use git as an underlying implementation detail, intentionally limiting many of the 'power' uses (at least without bypassing it and using git directly) but trying to solve an 80% target with simpler and less complex mental models.

Things that use git as a storage mechanism seem like a great idea - stop trying to 'fix up' git, just make a new VCS :)

Petter Måhlén

I think of Git a little like a squash racket for a pro player. Squash rackets for pros have a very small 'sweet spot' somewhere near the middle, and if you hit the ball right there, you get tremendous power. If you miss the sweet spot, you get a weird noise and the ball goes in a more or less random direction. Beginners' rackets have much bigger sweet spots, but never deliver the same power. Beginner players (like me) become worse, not better, by trying to use a pro racket.

Git requires you to invest a lot of time in understanding it. If you do, you get a great payoff - a VCS that does exactly what you tell it to do, no more, no less and does so with great performance. But if you're not going to be able to/want to make the investment in learning it (and keep using it daily so you don't forget), Git is probably not a good choice.

I think, like for squash rackets, it makes sense to have different tools for different types of users.


Is there a link to a recording of Simon's keynote somewhere?


I agree completely. For instance, the shop where I'm consulting right now decided to start using git-flow. It's a leaky abstraction on top of git, and until you understand what the abstraction is doing in terms of git, it's just 'magic' that often gets you into trouble. I think it's easier to just use git, as you have to understand the git 'model' anyway.

Also, I worry about developers who have problems learning git well enough to do basic day-to-day development. If they can't get that, then what hope do we have that they can design/code well? It's pretty much the same level of abstraction.


I guess I may not have used git enough to have run into trouble but so far... It just works. Things work as expected, and I am loving the push/pull functionality. Merging changes conceptually really is trivial unless there are conflicts, and conflicts are best resolved locally anyway - you dont let your vcs do something "smart" first because that will inevitably lead to a mess. That approach worked for cvs, svn, and now also git.

I have not done complicated vcs ops on git but I doubt it could possibly as byzantine as svn. And besides if you run into complicated version control system issues, 99% of the time, you're doing it wrong.

The comments to this entry are closed.