Git is conceptually simple, but has a baroque interface. It's nearly impossible to form a proper mental model of what's going on under the hood from its CLI.

The point of this article is that if you take the time to learn how git is actually constructed, the CLI becomes a lot more bearable, and is less likely to leave you in distress when Something Unexpected Happens.

I struggled for several hours last night to fix the history of a git-svn repo that had fallen out of sync. Eventually I started to grok it and the fix took all of two commands. I think that this semi-obfuscation may have been an intentional attempt to improve the SNR of kernel contributions - by putting in place a mild cognitive obstacle...

I wish I had written your first line!

I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated.

The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model.

FWIW, compare:

http://www.google.com/search?q=what%20is%20in%20.svn%20folde...?

with

http://www.google.com/search?q=what%20is%20in%20.git%20folde...?

All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.

> All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.

That would be because there's little to no content in the svn folders, and none of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel).

Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong.

Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy.

edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it expected that git users understand the content of their .git, it's pretty likely it will become necessary at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway)

[0] http://svnbook.red-bean.com/en/1.1/ch07s02.html

[1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/

[2] http://svn.apache.org/repos/asf/subversion/trunk/subversion/...

A better comparison would be between an explanation of the contents of .git and the contents of your actual SVN repo on the server. Since that's what the equivalency is.

My point is that to a naive user googling to figure out what is going on, the dotfile element of svn is inscrutable.

Well, to be fair, the title is not 'Git Is Simple'. I'm just starting to really use Git and after reading this it seems a little simpler to me. Personally, I think Git is relatively simple as far as version control systems go, it's forgetting 5 years worth of knowledge of SVN and the nice visual tools that support it that is hard.

I thought it was a little odd that he (seems to be) comparing the svn GUI with the git command line experience even though there are GUI tools for git as well.

Have you tried Tower (http://www.git-tower.com/)? I used it briefly for a small project and thought it was nice, but didn't really have time to get to know it that well.

I make daily use of GitX for visualizing the state of a repo, and it's got a pretty nice UI for building commits as well. (It's Mac-only, though.) Apparently there are several forks that have added new functionality on top of the version I use, but I'm comfortable enough at the command line now that I haven't bothered checking any of them out.

Yes I'm with you with this wccrawford. Git is not simple. Git internals may be simple hacks for hackers but git usage is another story. It does have neither understandable nor compatible terminology.

Because it's simple bash scripts but distributed and decentralised it has a steep learning curve.

No, no git is not simple. It's really complicated.

Git is mostly not bash scripts anymore:

    [~] 0 (jon@snowball2)
    $ file /usr/lib/git-core/git-status
    /usr/lib/git-core/git-status: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped

Thank you. I was misdirected by the article. And I have not peeked at the git source ever.